Created the ticket with a suggested implementation of TinyMCE:
http://tracker.moodle.org/browse/MDL-20139
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Olli Savolainen -
Number of replies: 31
In reply to Olli Savolainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
I will try to check the list and add some comments - I think I saw some tracker issue before where Martin and Petr discussed about buttons - for example media plugin that Petr took away from init code (for code checking)
DragMath is enabled only if TeX filter is enabled and this was particularly hard to understand for Marc Grober who is the maintainer of DragMath in moodle pre 2.0 and never uses TeX filter - he uses AsciiMathML. The workaround is to either hack locally init code of default TinyMCE or to create an additional configuration for second editor which I am going to do since editors will be pluggable in moodle 2.0 and I need my own plugins for mathematical notations in addition to core plugins.
In reply to Olli Savolainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
OK - I checked the first suggested implemention and added a lot of comments to tracker. I still hope that your suggested implemention won't be the implemented suggestion... 
In reply to Olli Savolainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
I hope other moodlers could comment these issues in http://tracker.moodle.org/browse/MDL-20139 and add other possible issues to tracker.
As a collection of most important notes and because we really don't know what different people (normal users) expect to see in moodle 2.0 (or do they expect anything?) could you please comment at least these. They are not self-clear - these are my opinions - not a plan of implementation:
---------------------------------------------------------
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
Now the main question is how selection of possible editor configurations should be enabled - in user profile (from given options), in editor itself with some kind of editor selector or editor profile selector (cookie based or user id based?)
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
In reply to Mauno Korpelainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Petr Skoda -
hey! thanks for these great posts, very interesting reading 
I agree the current design in HEAD is not suitable for anybody.
Please keep proposing and designing more solutions, I am sure we can get something easy to use for beginners together with extra flexibility needed for advanced users
This is my personal show stopper for 2.0, this must be solved properly before 2.0 beta.
Thanks everybody again!
I agree the current design in HEAD is not suitable for anybody.
Please keep proposing and designing more solutions, I am sure we can get something easy to use for beginners together with extra flexibility needed for advanced users
This is my personal show stopper for 2.0, this must be solved properly before 2.0 beta.
Thanks everybody again!
In reply to Mauno Korpelainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Olli Savolainen -
1) The part of Moodle users that even know about the editor changing for Moodle 2.0 is a small minority. Many of the university students I have talked to about moodle have thought it is being programmed in the university of Tampere or the technical university of Tampere, depending on which school they go to. Brings perspective to how much the "typical Moodle user" knows about Moodle development.
If we give advanced users the editor with all the bells and whistles you are requesting, we effectively cripple the editor for 80% (guess) of the users to unusable, just as my example from the usability testing above shows. Even two rows of buttons is too much for most use cases. In a development community it is hard to keep an eye on just how simple most users' use cases are. Wordpress' example may seem too simple but I suspect they have quite a bit of user research supporting their solution.
2) This is a good idea in essence, and might work after you discuss what the different presets might be with the community. It is completely out of reach of my current effort though, which is to defend the single reasonable default against feature bloat. I welcome you, however, to create this configuration UI or mockups for it in balsamiq and have the community get excited.
3) Could you demonstrate what the fullscreen_settings line would look like so I could take a look? The ideal to me seems to have an extra row of buttons available on user request, or when a selected tool/element requires it (table editing controls) (see above wordpress screenshot)
4) I see no relevant use for a typical user for the styles menu. It hogs up a lot of space.
5) 'Select all' could be added back if there would be space. I do not see it as critical, and it is not there in HTMLarea.
(Apparently the criteria is that the editor has to fit on 1024x768 screen without horizontal scrolling in a typical moodle form which has quite a bit of left margin. )
8) I interpret Petr's comments as those worries being possible to fix server-side.
9) Only paste broken on Firefox. Paste as plain text and Paste from Word give help on how to paste with keyboard so they seem to alleviate the problems caused by security restrictions. I removed paste now, will post a new patch at some point.
10) Since I can't imagine the options of advhr to really be useful to almost anyone.
11) I know, it seems funny. However, those functionalities are separate in most editors and word processors. The tinymce addition that you can switch between them with the tabs makes either seem redundant, but users likely search for these as separate functionality, so it makes the UI more fluid to have them both.
13) Is it IE-only, or why is the name iespell?
It is hard for me to comment on the special needs you have as a user, since they indeed seem special.
If we give advanced users the editor with all the bells and whistles you are requesting, we effectively cripple the editor for 80% (guess) of the users to unusable, just as my example from the usability testing above shows. Even two rows of buttons is too much for most use cases. In a development community it is hard to keep an eye on just how simple most users' use cases are. Wordpress' example may seem too simple but I suspect they have quite a bit of user research supporting their solution.
2) This is a good idea in essence, and might work after you discuss what the different presets might be with the community. It is completely out of reach of my current effort though, which is to defend the single reasonable default against feature bloat. I welcome you, however, to create this configuration UI or mockups for it in balsamiq and have the community get excited
3) Could you demonstrate what the fullscreen_settings line would look like so I could take a look? The ideal to me seems to have an extra row of buttons available on user request, or when a selected tool/element requires it (table editing controls) (see above wordpress screenshot)
4) I see no relevant use for a typical user for the styles menu. It hogs up a lot of space.
5) 'Select all' could be added back if there would be space. I do not see it as critical, and it is not there in HTMLarea.
(Apparently the criteria is that the editor has to fit on 1024x768 screen without horizontal scrolling in a typical moodle form which has quite a bit of left margin. )
8) I interpret Petr's comments as those worries being possible to fix server-side.
9) Only paste broken on Firefox. Paste as plain text and Paste from Word give help on how to paste with keyboard so they seem to alleviate the problems caused by security restrictions. I removed paste now, will post a new patch at some point.
10) Since I can't imagine the options of advhr to really be useful to almost anyone.
11) I know, it seems funny. However, those functionalities are separate in most editors and word processors. The tinymce addition that you can switch between them with the tabs makes either seem redundant, but users likely search for these as separate functionality, so it makes the UI more fluid to have them both.
13) Is it IE-only, or why is the name iespell?
It is hard for me to comment on the special needs you have as a user, since they indeed seem special.
In reply to Olli Savolainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
1) & 2) Interesting - if you check the version of your moodle in https://moodle.uta.fi/ it's
moodle 1.6.9 (2006050590) - how could your students know about moodle 2.0 if you are still using moodle 1.6 and they have not seen even versions 1.7-1.9 ?
Universities are the last institutions to rapidly change their production systems. I have upgraded our moodles rather regularly to the latest stable release so our teachers were asking about new release already last May when we had a training (VESO) for our teachers about moodle.
And note that we are now preparing moodle 2.0 for coming years and most moodle sites won't upgrade to moodle 2.0 before 2011-2012 (if moodle 2 is even ready then).
You are mostly talking about your students and your friends - I am mostly talking about our teachers and those people here in moodle.org forums (developers and administrators mainly?) that ask about different features in these forums
The whole meaning of my suggestion to give users different editor profiles in addition to default configuration is based on my 3 years experiments with different plugins and the simple thing that during the past 7 years moodle has never given users an option to change editors or skins of editors - or most features of editor - only administrators have been able to hide some buttons which most administrators never do like you said in one of your posts. The main keyword is FLEXIBILITY - read this post http://moodle.org/mod/forum/discuss.php?d=96160 for example - during the past few years I have used hundreds of hours with Marc Grober and others to create better tools for math teachers who have never had WYSIWYG plugins before DragMath for adding mathematical notations to moodle and next year we will have plenty of new tools for adding graphs and simple equations like
$$x=\frac{-b\pm\sqrt{b^2-4ac}}{2a}$$
with plugins. Your students may be able to write some latex notations with tex filter but my students have never heard about latex - they need WYSIWYG tools like Equation editor in Word or DragMath to see what their mathematical notations look like. Check http://www.imathas.com/editordemo/demo.html to see what I mean.
We could use TinyMCE plugins for many such new tasks that your students have obviously never used - for adding google charts (I am planning to publish such a plugin before Christmas) or google maps, Mihai's PaintWeb for editing images online, ImageMaps, stickers etc for primary school students or virtual keyboard plugins for writing with online keyboards for language teaching - see http://korpelainen.net/virtual.html
These features are never ment to by used by most users - but they are very useful and necessary for those users that want to use them or need to use them. If we had selectable buttons in our user profile Joseph could use non-breaking spaces in moodle.org with non-breaking space button, you could use minimal editor version with bold, italic and underline buttons and I could use all my favourite buttons without arguing which buttons must be removed from default editor - IF we had more than one configuration available. In HTMLArea we have not such options.
From the beginning of all our editor discussions during the last year we have talked about user-, role- and course based editors and settings but it was actually Storytelling that started the whole discussion.
3) Yes I can: See http://moodle.org/mod/forum/discuss.php?d=110079#p483279
fullscreen_settings : {
theme_advanced_buttons3_add : "tablecontrols"
},
It adds the needed table control buttons to 3rd row in fullscreen mode.
4) You have obviously never needed styles. It's ok if you want to write normal text - themes just tend to control the output and some things you write to HTMLArea just "magically" change and your students shout: "Hey - this editor shows totally different output than moodle - moodle stinks!!! The reason is that style sheets have quite many pre-defined styles that control most elements on screen and if no classes or ids are defined moodle picks up styles from browser default settings. With styles menu you can pick some of those same pre-defined styles that you moodle uses or add your own syles like pinky flower text with special effects to primary school girls to custom css file and give users this way a menu where they can select a ready format for whole text element with pre-defined css (fonts, colors, alignments, borders etc). I know that for most users it is an useless menu but only because people don't know what it could be used for.
9) Yes - Paste is a default button (that should not be shown) in TinyMCE itself that does not use any plugin. The confusing thing is that Paste is also a different plugin in TinyMCE that has three buttons: pastetext,pasteword and selectall that all require that you add to plugins list in init code plugin Paste...
Olli, are you saying that your Firefox allows you to use Cut and Copy buttons without message "Copy/Cut/Paste is not available in Mozilla and Firefox.Do you want more information about this issue?" - if that is true your Firefox may have a serious security problem and clipboard hackers can use your Firefox for anything they like...
10) Well if YOU can't imagine the options of advhr to really be useful to almost anyone of course you can change it to normal hr from left to right - those horizontal rules are pretty useless anyway so why would you care about width, height or shadow of rules. We should not use horizontal rules to separate chunks of content anyway if we believe what Jacob Nielsen has said...
11) How often do you replace text in editor with Replace button?
13) No - spell checker in TinyMCE uses by default Google spellchecker http://wiki.moxiecode.com/index.php/TinyMCE:Plugins/spellchecker but it can be configured to use PSpell/ASpell. You can test spellchecker in http://tinymce.moxiecode.com/examples/full.php - try to find a button with ABC from the 4th line
IEspell is a different plugin.
moodle 1.6.9 (2006050590) - how could your students know about moodle 2.0 if you are still using moodle 1.6 and they have not seen even versions 1.7-1.9 ?
Universities are the last institutions to rapidly change their production systems. I have upgraded our moodles rather regularly to the latest stable release so our teachers were asking about new release already last May when we had a training (VESO) for our teachers about moodle.
And note that we are now preparing moodle 2.0 for coming years and most moodle sites won't upgrade to moodle 2.0 before 2011-2012 (if moodle 2 is even ready then).
You are mostly talking about your students and your friends - I am mostly talking about our teachers and those people here in moodle.org forums (developers and administrators mainly?) that ask about different features in these forums
The whole meaning of my suggestion to give users different editor profiles in addition to default configuration is based on my 3 years experiments with different plugins and the simple thing that during the past 7 years moodle has never given users an option to change editors or skins of editors - or most features of editor - only administrators have been able to hide some buttons which most administrators never do like you said in one of your posts. The main keyword is FLEXIBILITY - read this post http://moodle.org/mod/forum/discuss.php?d=96160 for example - during the past few years I have used hundreds of hours with Marc Grober and others to create better tools for math teachers who have never had WYSIWYG plugins before DragMath for adding mathematical notations to moodle and next year we will have plenty of new tools for adding graphs and simple equations like
$$x=\frac{-b\pm\sqrt{b^2-4ac}}{2a}$$
with plugins. Your students may be able to write some latex notations with tex filter but my students have never heard about latex - they need WYSIWYG tools like Equation editor in Word or DragMath to see what their mathematical notations look like. Check http://www.imathas.com/editordemo/demo.html to see what I mean.
We could use TinyMCE plugins for many such new tasks that your students have obviously never used - for adding google charts (I am planning to publish such a plugin before Christmas) or google maps, Mihai's PaintWeb for editing images online, ImageMaps, stickers etc for primary school students or virtual keyboard plugins for writing with online keyboards for language teaching - see http://korpelainen.net/virtual.html
These features are never ment to by used by most users - but they are very useful and necessary for those users that want to use them or need to use them. If we had selectable buttons in our user profile Joseph could use non-breaking spaces in moodle.org with non-breaking space button, you could use minimal editor version with bold, italic and underline buttons and I could use all my favourite buttons without arguing which buttons must be removed from default editor - IF we had more than one configuration available. In HTMLArea we have not such options.
From the beginning of all our editor discussions during the last year we have talked about user-, role- and course based editors and settings but it was actually Storytelling that started the whole discussion.
3) Yes I can: See http://moodle.org/mod/forum/discuss.php?d=110079#p483279
fullscreen_settings : {
theme_advanced_buttons3_add : "tablecontrols"
},
It adds the needed table control buttons to 3rd row in fullscreen mode.
4) You have obviously never needed styles. It's ok if you want to write normal text - themes just tend to control the output and some things you write to HTMLArea just "magically" change and your students shout: "Hey - this editor shows totally different output than moodle - moodle stinks!!! The reason is that style sheets have quite many pre-defined styles that control most elements on screen and if no classes or ids are defined moodle picks up styles from browser default settings. With styles menu you can pick some of those same pre-defined styles that you moodle uses or add your own syles like pinky flower text with special effects to primary school girls to custom css file and give users this way a menu where they can select a ready format for whole text element with pre-defined css (fonts, colors, alignments, borders etc). I know that for most users it is an useless menu but only because people don't know what it could be used for.
9) Yes - Paste is a default button (that should not be shown) in TinyMCE itself that does not use any plugin. The confusing thing is that Paste is also a different plugin in TinyMCE that has three buttons: pastetext,pasteword and selectall that all require that you add to plugins list in init code plugin Paste...
Olli, are you saying that your Firefox allows you to use Cut and Copy buttons without message "Copy/Cut/Paste is not available in Mozilla and Firefox.Do you want more information about this issue?" - if that is true your Firefox may have a serious security problem and clipboard hackers can use your Firefox for anything they like...
10) Well if YOU can't imagine the options of advhr to really be useful to almost anyone of course you can change it to normal hr from left to right - those horizontal rules are pretty useless anyway so why would you care about width, height or shadow of rules. We should not use horizontal rules to separate chunks of content anyway if we believe what Jacob Nielsen has said...
11) How often do you replace text in editor with Replace button?
13) No - spell checker in TinyMCE uses by default Google spellchecker http://wiki.moxiecode.com/index.php/TinyMCE:Plugins/spellchecker but it can be configured to use PSpell/ASpell. You can test spellchecker in http://tinymce.moxiecode.com/examples/full.php - try to find a button with ABC from the 4th line
IEspell is a different plugin.
In reply to Mauno Korpelainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
Olli, one quick note to that link in 3):
Current moodle 2 has init code of tinymce in lib/editor/tinymce/lib.php and that's where code belongs. That post was almost 1 year old and init code was then in different file. Petr is also using different coding style so try this:
$fullscreens = array('theme_advanced_buttons3_add' => "tablecontrols");
$params = array(
'mode' => "exact",
'elements' => $elementid,
'relative_urls' => false,
'document_base_url' => $CFG->httpswwwroot,
'content_css' => $contentcss,
'language' => $lang,
'directionality' => $directionality,
'plugin_insertdate_dateFormat ' => $strdate,
'plugin_insertdate_timeFormat ' => $strtime,
'theme' => "advanced",
'skin' => "o2k7",
'skin_variant' => "silver",
'apply_source_formatting' => true,
'remove_script_host' => false,
'fullscreen_settings' => $fullscreens,
...
Current moodle 2 has init code of tinymce in lib/editor/tinymce/lib.php and that's where code belongs. That post was almost 1 year old and init code was then in different file. Petr is also using different coding style so try this:
$fullscreens = array('theme_advanced_buttons3_add' => "tablecontrols");
$params = array(
'mode' => "exact",
'elements' => $elementid,
'relative_urls' => false,
'document_base_url' => $CFG->httpswwwroot,
'content_css' => $contentcss,
'language' => $lang,
'directionality' => $directionality,
'plugin_insertdate_dateFormat ' => $strdate,
'plugin_insertdate_timeFormat ' => $strtime,
'theme' => "advanced",
'skin' => "o2k7",
'skin_variant' => "silver",
'apply_source_formatting' => true,
'remove_script_host' => false,
'fullscreen_settings' => $fullscreens,
...
In reply to Mauno Korpelainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
And if you have already buttons in normal editor mode theme_advanced_buttons3_add tag you need to include those "normal buttons" to those commands that you change in full screen mode. Commands in full screen mode override always commands in normal mode, they don't add init code to the same tags. So that line could look like
$fullscreens = array('theme_advanced_buttons3_add' => "|,tablecontrols,styleprops,visualchars,|,code,preview");
if you have used in normal mode
'theme_advanced_buttons3_add' => "|,table,styleprops,visualchars,|,code,preview",
Using this $fullscreens array you can define whole init code if you want for full screen mode but usually we need to add only a couple of buttons or a button group like tablecontrols that adds several buttons at the same time. Check also http://wiki.moxiecode.com/index.php/TinyMCE:Plugins/table to get more info about tablecontrols.
In reply to Mauno Korpelainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
It could be interesting to ask from students how many of them know that advanced table controls exist also in HTMLArea Full screen mode. In tinymce all tablecontrols are disabled until you have added a table - in HTMLArea and full screen mode you may have some problems in finding the actual table button from the second row first and you can still press table control buttons from 3rd row without any table related action. Our documentation is rather stub in this case
http://docs.moodle.org/en/HTML_editor#Inserting_tables
At least some teachers (I don't know how many though) use table controls because default button renders tables that do not look the same in differnt browsers - with table controls (or styles plugin) it is possible to change those styles of table, columns, rows or cells to make tables look more sophisticated.
The risk for not finding tools is much higher if we push them to full screen editor but it is a possible option if normal editor toolbar has too little space for buttons.
In reply to Olli Savolainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
I don't understand the point in
"If we give advanced users the editor with all the bells and whistles you are requesting, we effectively cripple the editor for 80% (guess) of the users to unusable, just as my example from the usability testing above shows. Even two rows of buttons is too much for most use cases. In a development community it is hard to keep an eye on just how simple most users' use cases are. Wordpress' example may seem too simple but I suspect they have quite a bit of user research supporting their solution."
I am not asking or requesting all the bells and whistles to "HTMLArea style default configuration". I suggested that we could (can!) have several optional configurations. How does it change the behaviour of simple editor if some users want to use advanced editor. If teachers want to use some plugin but want to hide it from students it is not possible in current HTMLArea - either that button is hidden from all users or all users see it.
Some people may want to use advanced features also in Wordpress although comparing Wordpress and Moodle is not very relevant.
See for example http://wordpress.org/extend/plugins/wp-super-edit/ and http://factory.funroe.net/projects/wp-super-edit/
It's odd if you in the name of usability want to prevent OPTIONAL advanced features because most users might (in your opinion) find them unusable. That way we should prevent people speaking Finnish and require that everybody should speak Chinese because majority of people speak Chinese anyway.
Default settings can be same for all users in Tampere and moodle.org but it does not mean that we could not have several optional configurations for different user groups and these "preset editor profiles" like Simple, Full, French, Math, Kids or Tampere could be selected the same way as we can select themes or languages.
I am not saying that all users should use the same plugins I like - I just named some plugins that are useful for me but useless for you (and therefore dropped by you)
I have always believed that flexibility is a good thing in learning environments - everywhere - and I am beginning to have a feeling that Usability is some nasty word that allows some people to define what others may do and particularly what they are not allowed to do. We have some rules of course that prevent using some plugins for some user groups but they can easily be handled with capabilities and roles - directly in init code.
If usability is defined as a "term used to denote the ease with which people can employ a particular tool or other human-made object in order to achieve a particular goal" I can say that usability of HTMLArea has not been very high for advanced use and I hope we will never come back to this current one-editor-one-configuration-built-in-system that we have in HTMLArea.
I like my 3 rows of buttons but I have nothing against it if you want to use only 1 row in your editor!!!
"If we give advanced users the editor with all the bells and whistles you are requesting, we effectively cripple the editor for 80% (guess) of the users to unusable, just as my example from the usability testing above shows. Even two rows of buttons is too much for most use cases. In a development community it is hard to keep an eye on just how simple most users' use cases are. Wordpress' example may seem too simple but I suspect they have quite a bit of user research supporting their solution."
I am not asking or requesting all the bells and whistles to "HTMLArea style default configuration". I suggested that we could (can!) have several optional configurations. How does it change the behaviour of simple editor if some users want to use advanced editor. If teachers want to use some plugin but want to hide it from students it is not possible in current HTMLArea - either that button is hidden from all users or all users see it.
Some people may want to use advanced features also in Wordpress although comparing Wordpress and Moodle is not very relevant.
See for example http://wordpress.org/extend/plugins/wp-super-edit/ and http://factory.funroe.net/projects/wp-super-edit/
It's odd if you in the name of usability want to prevent OPTIONAL advanced features because most users might (in your opinion) find them unusable. That way we should prevent people speaking Finnish and require that everybody should speak Chinese because majority of people speak Chinese anyway.
Default settings can be same for all users in Tampere and moodle.org but it does not mean that we could not have several optional configurations for different user groups and these "preset editor profiles" like Simple, Full, French, Math, Kids or Tampere could be selected the same way as we can select themes or languages.
I am not saying that all users should use the same plugins I like - I just named some plugins that are useful for me but useless for you (and therefore dropped by you)
I have always believed that flexibility is a good thing in learning environments - everywhere - and I am beginning to have a feeling that Usability is some nasty word that allows some people to define what others may do and particularly what they are not allowed to do. We have some rules of course that prevent using some plugins for some user groups but they can easily be handled with capabilities and roles - directly in init code.
If usability is defined as a "term used to denote the ease with which people can employ a particular tool or other human-made object in order to achieve a particular goal" I can say that usability of HTMLArea has not been very high for advanced use and I hope we will never come back to this current one-editor-one-configuration-built-in-system that we have in HTMLArea.
I like my 3 rows of buttons but I have nothing against it if you want to use only 1 row in your editor!!!
In reply to Mauno Korpelainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
Olli,
I need that Undo-button for my own comments
Comparing moodle to Wordpress is very relevant and I just installed latest Wordpress with plugin http://wordpress.org/extend/plugins/tinymce-advanced/ that allows administrator to drag and drop editor plugins and change their order in 4 rows. It's very easy to use.
On the other hand core tinymce plugin of Wordpress - named to "wordpress" - is also interesting. It adds that kitchen sink button (hide/show second row) but it also adds those custom media buttons over toolbar and custom keyboard shortcuts and some other common tasks.
I need that Undo-button for my own comments
Comparing moodle to Wordpress is very relevant and I just installed latest Wordpress with plugin http://wordpress.org/extend/plugins/tinymce-advanced/ that allows administrator to drag and drop editor plugins and change their order in 4 rows. It's very easy to use.
On the other hand core tinymce plugin of Wordpress - named to "wordpress" - is also interesting. It adds that kitchen sink button (hide/show second row) but it also adds those custom media buttons over toolbar and custom keyboard shortcuts and some other common tasks.
In reply to Mauno Korpelainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
The benefit of current system in moodle 2 is that it is possible to use different editors with separate files and we just need to add different configuration files (modified clones of current init code to lib/editor/editorxx/lib.php ) but a visual way to change settings might of course be preferable in the future (in moodle 3) - and more difficult to implement for multiple editors. Basicly we could add new editors and editor configurations exactly the same way as we add themes to theme folder and select site, course or user themes from installed options in administration menu, course settings or user profile. If no other editors exist in lib/editor folder default settings of default tinymce are used.
In reply to Olli Savolainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
I think the main conflict between your developing project http://docs.moodle.org/en/Development:Usability/Improve_Moodle_User_Experience_Consistency
and new features of moodle 2.0 (not between you and me or our toughts) is caused by the aim of keeping user experience consistent. It is a good principle in common - to make sure that users know where they are and find the old tools - at least most of them - easily. Using this principle we should probably create a new theme to tinymce that looks like HTMLArea (similar buttons in the same place) so that users don't even know they are using TinyMCE and not the old HTMLArea - and this can be done for default configuration and for most actions. I can create that icon sprite for TinyMCE if you want. It may help old users in finding old tools.
On the other hand it sounds odd if we add/develop new features but don't show them to users. Do you know any good resources (articles) about testing usability of new tools - such tools that users don't know before or that are added to improve old product but have such features that users don't know before and don't know what to expect?
Moodle 2.0 has more new features than any previous versions and that way it is a real challenge to keep user experience unchanged - but in my opinion it does not make new features less usable. Consistency is just one aspect of usability and the main target in developing new tools might be the goal - not history. The reason why we want to develop new features...
And to fulfill both these needs we should in my opinion offer both that old style editor AND new cool editor with all the advanced features - and some users (developers) may still prefer simple textarea and select from their user profile "When editing text - Use standard web forms" to keep their user experience consistent. 
In our Glossary Martin defines Usability:
"The effectiveness, efficiency, and satisfaction with which users can achieve tasks in a particular environment of a product. High usability means a system is: easy to learn and remember; efficient, visually pleasing and fun to use; and quick to recover from errors.
With software, the usability is very dependent on the interface."
The key for using new tools might be the first underlined text: easy to learn and moodle should give new users enough help in finding those new tools, learning to use new features and enjoy new tools that can be used to improve user experience and making our editor more efficient, visually pleasing and fun to use - and quick to recover from errors (remember the autosave discussions ...)
In reply to Mauno Korpelainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
Olli,
one of the "big questions" that we all should ask again is "Who are those people, end-users, that really need advanced features of editor?" because we are clearly talking about different user groups - just to explain why we need either selectable default settings or selectable editors/editor configurations for different user group. If we make usability testing purely from the viewpoint of a students and how easy or usable they find some tasks (in editor) when they write responces to forums or personal messages with smaller editor we never see the real need and users of advanced features.
The small minority of users - at least some teachers or professors - don't use moodle as a learning environment but as a teaching environment, teachers have more capabilities and personal needs and hopefully also interest to use different advanced tools for creating their course material with editor. Most teachers use tools like Word and PowerPoint or activities of moodle and they have been trained to use these tools but obviously very few people including teachers really know what they could use their editor for to make web pages and course pages inside moodle look better, feel better and this way make learning more fun ( I have sometimes argued about design of learning environment and asked which is better - asketic looking pages (so that all focus is in text) or visually enjoyable pages (with a risk that some part of focus goes to other elements than text). According to many studies age of students has influence - see for example http://www.useit.com/alertbox/children.html and kids moodle should not look the same as academic moodle in universities. And we have also Senior Citizens in adult education (my oldes student has been 82 years) who may have difficulties in using the PC and internet taken as a whole - read for example http://www.useit.com/alertbox/seniors.html
( Design is also one important aspect of usability - although web pages of usability guru Jakob Nielsen are really poorly designed... they may be usable and accessible but they look "sickening" if you ask from teens... )
We know rather well what kind of things kids are interested - many teachers have kids or teenagers - but we try to use same tools for all age groups. We could do amazing things with a kids editor - if we had such a tool. You have seen those flash sites where you can drag and drop cloths, stickers, animals etc, color pages etc and they can be added to moodle by teacher as flash resources. But we could have more tools like Storytelling, we could have simple buttons for kids that they can use for adding text, changing some nice fonts and colors and some plugins that they can use for adding those same cloths, stickers or animals to their texts just like you add smileys from smiley plugin. If we had such tools...
Now the problem is that it has been useless to develop this kind of tools for HTMLArea because HTMLArea has never allowed us to change plugins like TinyMCE does. Creating new plugins for kids for such tasks that I mentioned is easy in TinyMCE but we have missed the culture of creating age specific tools for kids during all those 7 years we have had moodle - and HTMLArea.
And this is part of many reasons why all other levels of education in my home town use moodle but primary schools use other tools that are created for children. Moodle has been too academic because most developers come from universities and have not seen the world of primary schools (or don't remember what it was like)...although world has changed a lot during the past 20 years...
Editor is of course only a minimal part of the whole moodle puzzle in addition to themes, activities etc.
For similar reasons I would love to see some changes in user profiles and how different fields of user profile could be selected, hided, ordered, styled or moved like I suggested in http://moodle.org/mod/forum/discuss.php?d=129719#p570671 and http://moodle.org/mod/forum/discuss.php?d=129719#p570653
But these are really big changes and I don't mean that you should change them - they are ideas for making future versions more user friendly and fun to use - not necessarely to keep concistency as a main rule...
In reply to Mauno Korpelainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
And after all these long posts:
Should we take a vote on those buttons and plugins that are needed by most users in default profile?
Button by button and menu by menu?
If we ask "What buttons could you drop from editor toolbar?" most users might drop most buttons as useless buttons.
If we ask "What buttons should not be dropped?" and "Why?" we might get other information
If we give first a list of possible default buttons and ask from administrators "What buttons would you add immediately to toolbar and what buttons would you hide/remove immediately?" we might get again different info...
If there is a clear consensus about default buttons among students, teachers and administrators task is easy and additional configurations can be created immediately according to voting behaviour and answers - depending on how many people vote and where...
Ideally such voting should be arranged by other people than us and for such people who have not seen these discussions and for different user groups (upper,secondary and primary schools - random sample among moodlers around the world... not the whole population but maybe 10 volunteer moodlers from different institutions could ask such data)
I'm afraid I will loose all my favourite buttons but it does not really matter because I can create those additional editor configurations if I need them in moodle 2.0.
( ... and I still don't have to speak Mandarin even if most people on Earth speak Mandarin - not English or Finnish ... http://en.wikipedia.org/wiki/List_of_languages_by_number_of_native_speakers - it's Democracy)
In reply to Mauno Korpelainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
Gosh... I forgot one important question:
"Are there some buttons in TinyMCE or elsewhere that might be useful for you in editor but do not exist in previous list or HTMLArea?" with some examples like DragMath (math editor), Non-breaking space, Spellchecker, media plugin and all possibly useful plugins we can find or people suggest but have never seen them in HTMLArea and haven't been able to use them before.
Any other good questions for a short survey?
In reply to Mauno Korpelainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Thomas Hanley -
Hi Mauno,
Thanks for all your thinking on improving this area of Moodle. Just a small contribution from me on the nbsp icon question!
I agree pretty much with Joseph that advanced users will figure out what this use is (tooltip will obviously help too for people who already know what a nbsp is).
I googled to see what icons other applications use. Almost all references were to Adobe Dreamweaver:
Only other example I could find was from Oracle:
The Dreamweaver example is similar to your example 1. So I would prefer example 1 or the Dreamweaver icon because at least people who are familiar with Dreamweaver or Oracle will (maybe!) recognise the icon. My logic though is somewhat undermined by the fact that I have used Dreamweaver alot in the past and I had no recollection of this icon! Also many people handcode so they won't be familiar with the icon either!
~thomas
In reply to Thomas Hanley
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
Thank you Thomas!
I think it might be good to send a post to actual forums of TinyMCE in http://tinymce.moxiecode.com/punbb/ and check some opinions from other systems using TinyMCE and particularly the developers of TinyMCE might be interested to comment the reasons why they have made different kinds of plugin / button selections and why they have not included some buttons or plugins - and how Moxiecode has selected the icons to their advanced theme sprite.
I'll be back on topic when we get some feedback from those non-moodlers...
In reply to Mauno Korpelainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
I think I found a treasure house, Olli!
Thanks to wise but short comments by main developers of TinyMCE, Spocke and Afraithe in http://tinymce.moxiecode.com/punbb/viewtopic.php?id=17625, I noticed that we started our usability testing from wrong tool. When Spocke said "...we have had common office suites as a benchmark..." I realized that we must ask what tools do most people use for editing text, what is the most common tool,... and the answer was easy: Microsoft Office Word and other Office tools like Open Office or WordPerfect - that's exactly where those basic tools to WYSIWYG editors come from and after some googling I found amazing stuff for example from
http://blogs.msdn.com/jensenh/pages/table-of-contents.aspx
Jensen Harris behind this blog is the Group Program Manager of the Microsoft Office User Experience Team.
Particularly this presentation (146 pages - it takes a long time to load!!!) is just fabulous:
http://officeblogs.net/UI/UX09_Harris.pdf
( if you want to check other formats go to http://blogs.msdn.com/jensenh/archive/2008/03/12/the-story-of-the-ribbon.aspx )
The most well-known buttons are the same buttons that people have seen in toolbar of Microsoft Word - and we must check the user experiences from developing versions of Office packages for the simplest default editor toolbar.
When this is done we (I) can start creating those additional editor configurations and after that we have at least 3 different ways to change editor configurations either by administrator (who allows people to use some butons and plugins) or by users who could select available editor configurations either from their profile or with editor switcher tool. I think I also know (at least one way) how to implement this but I must write the test code first and contact Petr after that.
In reply to Mauno Korpelainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
And if you have 90 minutes time to watch the whole presentation - The story of the Ribbon - visit http://videos.visitmix.com/MIX08/UX09 (video, audio and slides)
In reply to Mauno Korpelainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Oleg Sychev -
Hello, Mauno
I think you are quite right about having different editor configuration selectable (or even editable) by user - it is great. But I think that a software caller must also have a hand in the matter - different places in Moodle may require (or at least suggests) different configurations too.
I think you are quite right about having different editor configuration selectable (or even editable) by user - it is great. But I think that a software caller must also have a hand in the matter - different places in Moodle may require (or at least suggests) different configurations too.
In reply to Oleg Sychev
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
Yes, it's true and current moodle has different type of editor configurations already - editor of private messages has less buttons than "normal editor" and some activities like Wiki may use different buttons than some other activities. The traditional way in HTMLArea has been to hide some buttons with $editorhidebuttons but I don't think it's implemented to current code of moodle 2.0 at all - it should be easier to use just different init code (class selector) for such cases that require different editor - or some optional variable that selects which plugins are shown or which are hidden.
Moodle 2.0 has a totally new editorlib compared to moodle 1.9.
Image plugin has used all the time capabilities to show different image selection file for students and teachers (who have capability to manage files) and for example media plugin requires a similar check if it is used... so there is nothing new in role based settings...
The main change I hope is that all users don't have to see the same buttons - teachers may want to have some plugins that students are not allowed to use and students may have some buttons that teachers don't want to use...
In reply to Olli Savolainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
One more comment to this "useless" styles menu - I had a special use for it in my theme based editor integrations last year... I used it as multilang menu - the same lang menu as we have in HTMLArea to produce multilang spans for multilang resources.
But I was not satisfied because it is waste of good menu to sacrifice styles menu for multilang spans - unless you really need multilang spans in tinymce and if they are not implemented in core editor by other code & menu...
In reply to Mauno Korpelainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Geoffrey Rowland -
Hi
For what it is worth, I have attached the toolbar layout we are currently using with TinyMCE. I'm *not* suggesting this as a final solution (we have only just started using TinyMCE) but it may stimulate ideas. I also include a few relevant notes and concerns. I tried to take account of HCI considerations and also group related functions together, but moved a few buttons around so they would just neatly fit!
For what it is worth, I have attached the toolbar layout we are currently using with TinyMCE. I'm *not* suggesting this as a final solution (we have only just started using TinyMCE) but it may stimulate ideas. I also include a few relevant notes and concerns. I tried to take account of HCI considerations and also group related functions together, but moved a few buttons around so they would just neatly fit!
- The starting point was the full FCKE layout which, to my eyes, seemed closer to a Word-processor default than the full TinyMCE layout or Moodle HTMLArea default.
- The 3 toolbar layout may be overkill (but I like all my buttons!). Although not shown, the full-screen, expanded toolbar includes the extra table editing options. It could also include the TinyMCE CSS functions (currently left out) for 'expert' use.
- I remain uncertain about the 'New document' and 'Save' buttons (top left). They are in the same place as a Word processor. The Save button does duplicate existing functionality, but I often find it convenient not to have to scroll down the page to find the Moodle form [Save] button. However, I appreciate that users may get confused between saving (posting) to Moodle and saving to their local directory. I'm also not sure whether the HTML code view and Preview buttons should be in this cluster on the top-left or in their 'traditional' (Moodle HTML Area, TinyMCE) place on the bottom-right.
- There are probably too many paste options, and to be honest I'm not sure about the precise functional differences between them. However, the ability to clean up content pasted from, say, MS Word is vital. I'm just not sure whether this is robust enough in TinyMCE to 'just work' or whether there should be specific options.
- I prefer drop-down menus (Font family, Font size, Font Format) to be on the bottom toolbar not on the top (current Moodle and TinyMCE default). Currently, I have not included a Style.
- TinyMCE is increasingly common on other, perhaps Moodle-linked, systems e.g. Mahara and Alfresco, so it would be good if there was consistency in toolbar layout between them. Of course, there is no reason why the Moodle layout shouldn't take the lead in this.
In reply to Geoffrey Rowland
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
Thank You for your comments, Geoffrey!
The more I think the default configuration the more I agree with Olli and the more I look at your toolbar the more I think we should all be individually able to select our own buttons for advanced toolbar... who ever you ask they suggest different buttons.
One interesting point in the latest versions of tinymce is that if we read http://wiki.moxiecode.com/index.php/TinyMCE:Plugins/paste it says about Paste plugin:
"The new version will auto detect word contents and automatically clean it up before inserting it to the editor. So there is no longer any need to use the dialogs to paste contents from third party sources."
It means that for example [paste_auto_cleanup_on_paste] is automatically enabled and if user pastes contents from Word with Ctrl+V messy code will be automatically cleaned... unless init code defines something else.
For a while I imagined that my task is now to take away all those buttons from your toolbar that most people will never use in their everyday use - I tried to be realistic but my own habits may have some influence. Red color indicates "vanishing buttons" that are used very rarely and may fit to advanced toolbar but might not fit to simple default toolbar if we need to keep only essential buttons for all users...but I am happy to not be that person who must choose the "essential default buttons for all users".
In reply to Mauno Korpelainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Geoffrey Rowland -
Hi Mauno
I agree with much of your 'red colour' in defining a minimal rich text editor.
Given your comments above, all but the simple 'Paste' should go. I also have no qualms getting rid of 'Direction left-to-right', 'Direction right-to-left', 'Full justification', 'Prevent automatic linking', 'Insert/Edit Anchor','Insert Date', 'Insert Time', 'Show/hide control characters' or the 'Custom horizontal rule'.
However, I have a few reasons for keeping some of the others:
1. I teach Science and Computing, so want my 'Superscripts', 'Subscripts', 'Characters' and 'Equations' (by the way, thanks for all your work on this!). Similarly I like to format code snippets so want the 'Paragraph' menu. I also want students to use these too! That said, I understand that some may deem this a specialist use.
2. I also anticipate the way the Moodle rich text editor is used is changing. Up to now, I have largely used it for labels, titles, short descriptions, messages, relatively short forum postings etc. Indeed, for the most part, I could cope without a *rich* text editor at all. Any complex writing and formatting was done in MS Word or Open Office and uploaded as a document file to Moodle.
However with the emergence of Google Docs and similar Web-based applications, I suspect users will become familiar with and expect more feature-rich online editors and toolbars.
A specific example is that we are starting to use the Moodle ILP module to generate online reports of students' progress (replacing our existing paper-based formal reports). These will be read by students and parents, so it is essential that they are professionally formatted with correct spelling etc. So in this context, novice users (i.e. lecturers) will really appreciate their familiar Word processing icons of 'Select all', 'Cut', 'Copy', 'Paste', 'Undo', 'Redo', 'Search', 'Replace' and 'Spell Check' (aspell, not iespell). Similarly, I make quite a lot of use of 'Strikethrough' (e.g. to show something has been completed) and a basic Horizontal rule (to group and separate content).
3. I would also hope that a well designed toolbar (with meaningfull mouse-over descriptions, short-cuts etc) has an educational (dangerous talk!) use in 'tempting' users to explore and understand unfamiliar functionality. Hence, I retained a 'Blockquote' button (not for indenting!) because I want users to correctly identify substantial quotes. The one thing you can be sure of is that a feature won't be used if it's not there!
4. Of course, I have my own 'pet' hatreds. If I had my way, I would probably get rid of 'Background colour' and perhaps even 'Text colour' and 'Centre align' - though most users seem to love the instant control they give.
I guess that is one fundamental issue. Do we give users what they want or what they need?
I agree with much of your 'red colour' in defining a minimal rich text editor.
Given your comments above, all but the simple 'Paste' should go. I also have no qualms getting rid of 'Direction left-to-right', 'Direction right-to-left', 'Full justification', 'Prevent automatic linking', 'Insert/Edit Anchor','Insert Date', 'Insert Time', 'Show/hide control characters' or the 'Custom horizontal rule'.
However, I have a few reasons for keeping some of the others:
1. I teach Science and Computing, so want my 'Superscripts', 'Subscripts', 'Characters' and 'Equations' (by the way, thanks for all your work on this!). Similarly I like to format code snippets so want the 'Paragraph' menu. I also want students to use these too! That said, I understand that some may deem this a specialist use
.2. I also anticipate the way the Moodle rich text editor is used is changing. Up to now, I have largely used it for labels, titles, short descriptions, messages, relatively short forum postings etc. Indeed, for the most part, I could cope without a *rich* text editor at all. Any complex writing and formatting was done in MS Word or Open Office and uploaded as a document file to Moodle.
However with the emergence of Google Docs and similar Web-based applications, I suspect users will become familiar with and expect more feature-rich online editors and toolbars.
A specific example is that we are starting to use the Moodle ILP module to generate online reports of students' progress (replacing our existing paper-based formal reports). These will be read by students and parents, so it is essential that they are professionally formatted with correct spelling etc. So in this context, novice users (i.e. lecturers) will really appreciate their familiar Word processing icons of 'Select all', 'Cut', 'Copy', 'Paste', 'Undo', 'Redo', 'Search', 'Replace' and 'Spell Check' (aspell, not iespell). Similarly, I make quite a lot of use of 'Strikethrough' (e.g. to show something has been completed) and a basic Horizontal rule (to group and separate content).
3. I would also hope that a well designed toolbar (with meaningfull mouse-over descriptions, short-cuts etc) has an educational (dangerous talk!) use in 'tempting' users to explore and understand unfamiliar functionality. Hence, I retained a 'Blockquote' button (not for indenting!) because I want users to correctly identify substantial quotes. The one thing you can be sure of is that a feature won't be used if it's not there!
4. Of course, I have my own 'pet' hatreds. If I had my way, I would probably get rid of 'Background colour' and perhaps even 'Text colour' and 'Centre align' - though most users seem to love the instant control they give.
I guess that is one fundamental issue. Do we give users what they want or what they need?
In reply to Geoffrey Rowland
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
Good points, Geoffrey
In my opinion we must give users both what they need and if possible also what they want and we need our 3 rows of buttons even if some people don't need a single button. Default configuration can have one or two rows of buttons (who knows what they should be...) - but those people who need LTR/RTL, spellchecker, multilang menu etc must find them when they need them - even if they were not visible in default configuration.
We must just find a smart way to give different users different toolbars according to their different needs. One way to do this could be user selectable editor profile (simple/advanced/custom) or selectable buttons in user profile - one variable that has a string of available buttons (id) they could show or hide if allowed. Another way could be to use those "kitchen sink buttons" - to add editor itself 1-3 mystical buttons that open a new toolbar or group of buttons - or an external toolbar. Microsoft used those tabs in Office 2007 when they ran out of space... or we can add a selector to editor that allows us to select one of available editor "format" or customize our own format...
The big question is just how to make it simple - easy to learn, easy to remember, easy to use, easy to find and maybe even easy to customize... and the task itself to make all this simple isn't so simple anymore...
In reply to Geoffrey Rowland
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
Maybe the only way to find out what people really want and what they need is to ask - I will create a quick anonymous online button survey and try to get enough different moodlers from different countries and different user groups to fill that survey.
Links to that "open survey" should be available within some days (next week?) and results should be visible next week as well. At least a short survey like this might help in creating those additional toolbars, selectors or editor profiles - without need to arrange large user action follow-up studies.
Yet a survey like this may not have any impact on those decisions that Petr and others finally do but we may get some interesting info about user experiences anyway.
In reply to Mauno Korpelainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
After some non-functional tests with switcher code and discussions with a couple of teachers I decided to leave surveys for some other time and suggest that we take all available (needed) buttons and menus to default configuration but select only the most common and well-known buttons to 2 first toolbars (see number 4 in attached image). Other buttons and menus can be taken to FULL SCREEN init code which does exactly the same thing as any other magical buttons - switches on the advanced buttons that can be set to even 4 rows in the future but should fit well to 3 rows in current tinymce.
Because screen is wider in full screen mode we can add new buttons also to 1st and 2nd row but we have lots of free space in 3rd and 4th row as well (see number 5 in attached image)
First toolbar is current HTMLArea, second toolbar TinyMCE from Moxiecode (Full example) and third toolbar is from current moodle 2.0.
In reply to Geoffrey Rowland
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Mauno Korpelainen -
I tried to check a few other CMS systems some days ago and noticed the same thing as we notice in comparison of our custom toolbars that there is no such consistency every CMS has different buttons and it's amazing. For example here is toolbar of Joomla:
In reply to Mauno Korpelainen
Re: Usability: Usability of toolbar and buttons of TinyMCE in moodle 2.0 (was One solution for Keeping user data safe)
by Victor Jimenez -
Hi Mauno, i have a two problems: 1. I dont speak english je,je,je i speak spanish, 2. I work whit tinymce_integration, but need upgrade a new version to tiny. You install a new version?, please help.