apparently https://tracker.moodle.org/browse/MDL-41503
i didn't spot it on the new features forum, but it looks like hq have rolled their own yui based editor.
more stuff here https://tracker.moodle.org/browse/MDL/component/10070 including the 'produces ugly html' which is guess is rather relevant for themes.
anyone know if there is a ticket about moving moodle to the greatly improved tinymce4 http://www.tinymce.com/presentation/?
gets a +1 from me, purely on the basis of acessability.
+1 from me too!
I did see a while back about the inclusion of the new Atto editor and I thought that it was better than TinyMCE 3. But now that I see TinyMCE4 that looks like a better option...
but (flaming here) I don't think it will ever be included because it uses that darned jQuery! And YUI is just as good or better than jQuery, blah blah blah...
Could an admin move to the new editor on their own?
Well... https://tracker.moodle.org/browse/MDL-40421
It does not make any (big) difference if you integrate Atto (ContentEditable) or any other HTML editor to moodle 2 - somebody just needs to do that "hard work" and write the code for necessary plugins.
TinyMCE 4 is a great option - the most natural successor of Tinymce 3 that is pretty stable now (still has some tiny bugs) - and core editor could be as well http://ckeditor.com/
For me the main purpose of editor is editing text and adding content (images, embedded content etc) and formatting text. Editor skins could be nice extra for themes but I have not seen theme designers using much real editor skins - the different looking editors are mostly color variants of each other. Tinymce 3, Tinymce 4 and CKEditor are all "themable" - they can have different editor themes, different skins and different skin variants - or use core theme css.
On the other hand usability experts might prefer a stable, constant look - no changes to buttons and functionality of buttons in toolbar... and once you take one button away from editor toolbar or move it / change the icon you get questions like "Where is this button?"
Tracker had issues about optional editors already 10 years ago
Hi Damyon
Did you have a look at http://codepen.io/trhino/pen/xyLAu
Kinda does the same but with about 5 lines of js - might be easier to maintain and faster for the browser?
Danny,
no fear - Tinymce 4 does not need jQuery or YUI - both TinyMCE 3 and TinyMCE 4 can be used with or without jQuery/YUI so that does not prevent integration of tinymce 4.
Thanks Mauno for the info. it seems that there's 2 versions available, a "standard" build and a "jQuery" build. I can't seem to find any documentation of what the differences actually are (and people are asking at other projects that use TinyMCE)
but if I had to guess the jQuery version is probably just "lighter" because it can use the existing functions rather than defining its own. Which would make it a better option for any project already using jQuery.
But as you said, not necessary
An example of old editor discussions:
https://moodle.org/mod/forum/discuss.php?d=19648
Moodle 1.5 had no worries about mobiles or tablets yet people were interested in optional editors mostly because support for HTMLArea was discontinued in 2005 and HQ developers had to do all future bug fixes themselves. It took 5 years to finally change default editor integration in moodle 2 to tinymce 3 (in 2010). So my guess is that IF moodle is going to have a new default editor it will be in moodle 3, tinymce 4 and year 2015
Note, you can configure which buttons TinyMCE displays to users. http://docs.moodle.org/24/en/Text_editor#Customising_the_editor_toolbar
Amy, As I've commented in other threads about the editor - its all very well in some instances (maybe even most) to restrict the size, colours and other features. But there are situations where they are needed.
The use of colour in highlighting features can be important - as it can be when creating pages for young children. Moodle is not only used in high schools and above! Appropriate sizing of text for age groups of children can also be vital. If you look at printed materials for Nursery to Year6 (Early Years through Primary) they will have different font sizes, but are likely to be in one school with one Moodle theme, so teachers/content creators NEED those features. And those Primary school teachers are NOT likely to know, or want to know about HTML markup!
The idea of having multiple editors/configurations available so that the admin (or even the user) can choose the most appropriate one, so that those tools are only made available when they are needed is a good one, but they should be available when they are!
I've actually achieved something similar just in TinyMCE (my coding skils aren't up to creating a new editor plugin!) by providing a restricted initial set of tools (encouraging people to use the preset styles rather than just making things bigger and bolder for example), then using the PWD plugin to allow the user to expand them to get the full tool set when needed. It doesn't stop people doing silly things, but it does take it one step further away and make them think rather than just do, yet it allows those that need it to still have easy access to those tools.
spent a while on the net today and started to take screenshots of places where you create content.
is it just me, are there literally no websites that the majority of our users create content on that use one of these WYSIWYG editors as the interface?
interested to know peoples thoughts on why that is?
what insite into users behaviour did all these rather popular websites have that made them stop using wysiwyg things?
and how does it effect peoples use of these sites?
But is Moodle more of a social platform than perhaps a bloging / content creation website like Wordpress / Joomla / Drupal which I think still have WYSIWYG editors? So in social mediums you want a consistent style but in publishing you want to facilitate variety with an underlying consistent scheme.
Or should we be thinking differently, having plain editors and powerful theme customisation?
Education is all about providing the Edutainers with the tools to express themselves in the style upon which they educate and thus facilitating engagement through apparent enthusiasm.
here's a couple of wordpress examples:
So it seems the default (at least now) in wordpress is a plain text editor.
I believe that other editors (google, etc..) have a markdown/up syntax that you can use to do things like italics etc... but it's not shown by default, so here's a theory:
The users that NEED those features will go out of their way to use them because it's a necessity. When all of those features are available people start using them because they CAN. and we all know can !== should.
Well said Danny
The users that NEED those features will go out of their way to use them because it's a necessity. When all of those features are available people start using them because they CAN. and we all know can !== should.
Perhaps that is the way forward to provide a clean interface and yet keep the functionality available when required.
Although I find myself in this post manually editing the HTML and using the 'blockquote' tag!
yet keep the functionality available when required
Is exactly what I have been arguing for all the way through both this and Stuart's 'can we drop TinyMCE yet' thread!
Its one thing to say we need a cleaner interface that stops most people making fools of themselves when they dont know what they are doing. But what often seems to come out is lets stop anyone doing anything because we dont like them having control themselves.
A balance is needed - cleaner smoother better (default) user interface, yes. But the 'power tools' need to be (relatively) easily available too for those that need them - and that doesn't mean having to learn mark up languages.
Sometimes in finding a solution you have to take the long way round to understand why the destination is the right one.
For students to engage maybe its just got to be like the other things they use on the web? So i'd guess social is the norm now?
Experience suggest that is true for younger (<36ish) staff too.
The social vs publishing thing is an interesting one though!
In publishing us authors don't expect to have to do our own formatting for print publication or research publications - can you imagine the outrage ;)
As an author i am more than happy to have an expert do all that gubbins for me, its their job to make my content look beautiful with well chosen paper, colour, fonts, line-heights, kerning, layouts etc. I'm fine to consult on the cover, give images etc but there is no way i'm learning all that other stuff!
That thing we used to do called desktop publishing still has a bit of a hangover though.
That default use of ms word (other products are available) - which before recent versions - spits out pretty ugly homogenous 12pt times new roman (calibri if i'm lucky) documents, helped created an unfortunate prerequisite that for most of us users & organisations we had to spend time styling our content for it not to look so homogenous, and that created our need for an overwhelming array of formatting options we could try and use to achieve this.
Having watched A LOT of people using desktop publishing tools, i understand that almost no one really knows what they are doing, but we work around and click stuff until we get pissed off, or in some cases it actually works! For most of us its rather experimental, and we do like to express ourselves, which leads to some rather interesting formatting choices - like some of the 'outsider art' formatting i've witnessed
I recon this all leads to one reason often quoted for having a wysiwyg editor on the web - its on my computer screen- its like word/desktop publishing or something, and i'll need lots of options because i'll have to do all the format myself.
The default format/stylesheet provided by websites in the past didn't really help with this either - arial,lucida,verdana,tahoma, ugly, yawn and we all ended up with feature rich word style wysiwyg editors.
So yeh, is that where we are at now?
Taking a look at the web today though - you have webfonts, grids, css3, html5 semantic markup etc etc - so i can publish pretty hip looking content without me having to try pressing all those buttons up there - http://www.tumblr.com/themes/tagged/minimalistic
So i guess the question is - is it really still like word doc/desktop publishing where i have to mess around with all those all options to make my stuff try and look nice?
or is it more like print where you stylesheet/designer folks can take all that pain away and just make it look nice for me?
all manage it, so as theme designers i recon you should all be able to do all that for me without me having to think about it to much.
now fly monkeys, while i get on with my real job of writing up an article on user experience yeh?
Stuart,
it is very simple. Each user has custom user experiences.
Some people need simple things and help to use even these simple things - some people need more advanced tools and have capability to learn how to use these tools.
If you some day need a calculator you probably take any tool available like http://www.online-calculator.com/simple-calculator/
I have no personal interest to use all the buttons and tools of my calculators either but because I teach advanced mathematics and our studentents use tools like http://edu.casio.com/products/classpad/cp2/ I need to study how to use such tools myself too.
You are right - for 99% of users 99% of editor buttons are useless - but if that 1% of users happens to really need buttons like "Insert non-breaking space character" (french) or "Insert equation" (disabled here) and they kick up a fuss.
User preferences could be used to select personal buttons for each user, user group, course, category, theme etc but this feature has not been (so far) implemented to core editor. Moodle itself does have the code - how to set user preferences and how to get user preferences, they simply are not used in core editor. Moodle has a user policy to use similar default tools for all users and administrators can change certain optional features and those users who are not satisfied just need to live with it...
wtf is that image Mauno? pretty hilarious, thanks for sharing
A couple of years ago that norm was "Office-tools" and it still is for many ">36ish"
Typically teachers don't use editor for changing layout of text - they use tools like MS Word for that purpose and ask also students to attach files to their learning tasks. So if you need to satisfy only 99% of site users leave image plugin, link plugin, media plugin and disable rest of the buttons in your site editor toolbar.
Stuart,
How many of those sites are people actually trying to create full content for a web page creation tool and how many of them are simple 'post to forum/chat' input boxes?
If Moodle is to become a simple post to forum social page (for which there is already a course format) then limiting the input mechanism to plain text/minimal formatting may be beneficial. For as long as the same editor is also used to create the main content on the pages of Moodle, then I would still say that some people, in some situations, will continue to need those tools available - not necessarily as the default editor, but available and in easy reach.
The alternative is what I have already experienced happening on an alternative commercial LMS system, where the tutor actually constructs the content in an external program, formatted and laid out as required and it becomes a separate embeded file or even in one instance I have seen, got produced as an image file embedded as part of the page. Plays hell with the page layout even on my PC as the embedded content would appear to be fixed width and you can imagine what its like on a mobile device, let alone the impact on accessibility and screen readers and the like!
All of those sites prevent the input of HTML to prevent users from inserting malicious code. They don't really compare to Moodle's normal usage. It's apples and oranges.
A better example would be comparing content writing systems: Joomla, Wordpress, etc to moodle.
hi jason,
i guess you have to think about how many students there are using moodle compared to content editors/creators.
as this thread highlights quite often - giving students (and most teachers!) something like a joomla/wordpress editor isn't what they need.
what do you think the percentage would be, and what do you think the different demographics needs are?
That's what Atto is for though, the new WYSIWYG editor. It allows minor, basic changes to be made, without all the extra bloat and nonsense that TinyMCE has.
That 'bloat and nonsense' though are the essential tools for other people!
There will be a user preference, so they can pick and choose what they need themselves...
more options and choices = poor user experience though right?
http://en.wikipedia.org/wiki/Hick's_law
It's so easy to missuse this kind of "laws".
Increasing the number of choices may increase the decision time but "one size usually does not fit all"... one theme does not fit all, one editor does not fit all, one opinion does not fit all.
No Stuart it doesn't
Badly designed UI creates poor user experience
Not being able to do what I want/need to do easily creates poor user experience
Options and choices, properly presented = Good user experience (in my experience!)
if thats what its for, why doesn't it do that?
from a js code perspective - atto is much larger and more complex than most contenteditable solutions on the web http://codepen.io/ElijahFowler/pen/fyILl and the yui dependencies seem rather redundant.
from ui - you would be hardpressed to tell to from any other wysiwyg editor found online publishing systems such as joomle, wordpress n drupal - it is much more similar to tinymce than any of the common ui screenshots in this thread.
So its not really very modern or what our 99% of users are used to on the web these days is it?
In my opinion, it does do that, perfcectly. Yes, there is more code in it than most contenteditable solutions on the web, but those other systems don't have to integrate with Moodle's repos etc. The YUI stuff is so we can have unified UI throughout Moodle - you may be noticing a theme in my responses here, as we are striving to unify the UI of Moodle's core components.
Yes, the UI is similar to TinyMCE, we wanted to create a cut down version of the editor that people would be familiar with.
Our users are used to TinyMCE, so it is what 99% of our users are used to - you've said so yourself.
At the end of the day, Atto is being developed, it's for the benefit of the community. It works well, is faster to load than TinyMCE and it has less of the "ugly controls" (font, colour and table) than TinyMCE. It's in core. That doesn't mean other editors won't make it in, or can't be used.
for 99% of our users moodle is not the primary thing they use on the web - the webpages in the screenshots within this thread are used by moodle users far more than moodle is.
Your users, or students and teachers as we normally call them, don't spend all their time in the lecture hall or class room. That does not mean your university should move every class to the pub (thought that might be initially popular with the majority of users, it is not necessarily going to improve your course pass rates or educational outcomes).
hi tim,
it seems you are suggesting that learning can only occurs in the lecture hall or class room - and never from any use of the internet, social interaction or use of external media - i'd be really interested to see any data you/the OU have on this?
cheers
stuart
No Stuart, to follow the analogy through what I think Tim is implying is that you want all learning to happen in the pub. You keep going on about how most of your users spend most of the time using tools such as social media, so Moodle apparently, in your reckoning, must become solely a social media tool, with a twitter/facebook style editor and no/limited choices for users.
Yes, students all use social media tools, of course they do - but that does not mean that those tools are the best ones for a job. All carpenters use a saw - ever tried hammering a nail in with one of those? You need a range of tools and the choice of which one is most appropriate to the task.
To bring the OU back into this debate and to follow your logic again. I would esitmate that at least 99% of your users watch the TV. Should the OU go back to only using those 1970s/1980s TV broadcasts we all remember (or those of us old enough) for their distance learning - because thats what 99% of their users use???
No - its not appropriate is it! well neither is the constant repetition that 99% of your users use social media tools so the moodle editor has to look like one of those.
Now, having thought we had reached a consensus between most of the people involved in this discussion previously. It seems to have been re-opened, with you again taking the stance in most of your posts that the only way forward is your way. I think that is probably what Damyon means when he suggests that some of your comments are not helpful to the discussion!
The way I see things, HQ have decided to go with Atto, regardless of the issues that have been put forward relating the history of what happened with the htmlarea editor and appear to be saying that HQ will not be working on TinyMCE4, that will be up to the community. So, if you really do believe in the consensus that you touted previously, please get behind those issues and start helping improve Atto and Mauno's 'community' project to get TinyMCE4 as a community plugin in rather than banging on constantly about 99% of YOUR users only use/want/need the barest minimum tools. That would be constructive comments in the discussion!
is it me or is everyone going bonkers? Have any of you seen the amount of cross posting threads here all talking at odds with one another, in some cases quite opposing arguments.
I don't think anyone has any real liking or disliking for a particular text editor. And I think the main reason that Atto was chosen at the last minute is so that Clean theme can be the Standard theme in Moodle 2.6 that has an editor that is fully responsive.
Lets face it everything has to be Mobile oriented now. So what Stuart is saying is correct in that we only need a few tools to add those elements we need when using a Mobile.
Anyway, I have not seen anything in Stuarts comments to suggests he is bullying or at odds with anyone, he is just expressing his opinion about something he feels very strongly about. If anything, though, I think he has been totally misunderstood. He also very rarely answers you if you are too wordy...so here is hoping this will be ignored too.
Cheers
Mary
I think this kind of discussions are good for getting new ideas - by the way are mobiles/mobile users really setting all standards? Content management systems are going through similar process as webmail/email client/mail apps and like Danny said editor in mail.gmail.com is starting to look like Atto and TinyMCE in moodle 2.6 - see https://support.google.com/mail/answer/8260?hl=en&ref_topic=3396256
and after some clicks
But HTML5 allows much more! HTML emails can be responsive in good and bad (phishing)
Some people like to use phone only for speaking - some send responsive emails with smart phones
http://www.emailmonks.com/design/email-newsletter-designs.html
http://blog.stamplia.com/actuality/responsive-emails-the-future-of-email-marketing-2/
So should emails be always text because 99.9 % of students send only text emails? Should email apps support only text input for the same reason?
No - but for "default tools" obviously yes.
10 years ago many people thought that the only correct way to input HTML is writing source.
5 years ago default editor of moodle did not support other browsers than IE and FF because majority of users used those browsers.
Today everybody clearly wants to hide such tools that create HTML and allow some kind of switcher button for plugin lovers - sorry for crosspostings
Email apps have much worse HTML/css support than mobile browsers but it does not prevent salesmen sending HTML emails - see attached pdf file
Hello Moodlers and Text Editor aficionados
I just came across this discussion while I was searching for something else, and thought it just goes to show who was right and who was wrong.
How many of you still use TinyMCE?
+1 from me!
Cheers
Mary
I do!
I do, too. I am waiting for ATTO to support "shift-enter" line breaks properly. I think that could be about it.
Me - Atto is getting there, but it still doesn't have anything like the power and flexibility of TinyMCE
For me the big feature we use that Atto doesn't provide (yet) is the pre-made templates. Admittedly thats not a core feature on the Moodle installed version of TinyMCE either, but it is one that can fairly easily be added
I also support Moodle in a number of Primary schools, and the way they use TinyMCE to provide colours and styles differs from Nursery to Year 6, so the couple of schools that I did leave Atto as the default came back to me and asked for 'the old editor' back.
I have a few reasons for Tiny MCE.
1. It has many more classes included than ATTO (responsive table being most important in my world).
2. The cloze editor plugin - while this really belongs in the Cloze question type, for now it is the only way pretty much to write cloze questions without writing some sort of code.
3. Basically more options.
if i was trolling i would have just gone with "Any sufficiently advanced bug is indistiguishable from a feature" - R. Kulawiec
as it is, i'd like you to justify that by listing anything i have posted that you think is not constructive or helpful please.
Hi Stuart,
I am the Moderator here and taking notes, so you better watch what you say or I'll have to delete this discussion...the whole of it. LOL
And, also as this thread highlights quite often - giving students and teachers the extended tools to do the job sometimes is what they need - but lets not get back into that argument, having come to some consensus about the need for BOTH a slimmed down editor for those that dont need the additional tools and the full fat one for those who do
And the contrast of students v content creators isn't always a valid one - the online assignment tool is very useful with the full editor (Ive had 7-8 year olds making web-pages and posters using that and Moodle Pages - and no need to teach them HTML markup )
I disagree, all of those sites sanitize user input to prevent users from inserting malicious code. Most of those sites actually allow limited HTML input or markdown - they just don't make it obvious immediately because it's not necessary (99% of the time) for users to have need to.
Stuart,
we may disagree about number of necessary buttons but I agree with you that we should get tinymce4 to moodle 2 as soon as possible - first as an optional editor and later (maybe) as a default editor.
The tracker links to Atto editor were useful - and some core developers seem to be working on "similar look of buttons in Atto and TinyMCE" ( MDL-40770 and MDL-42102 ).
If they had known that tinymce.com has launched a bootstrap based skin creator
a lot of valuable time could have been saved for adding tinymce 4 integration to core (as an optional plugin)
I don't see how swapping to TinyMCE 4 will be easy. We have a lot of custom code that will need reworking to make it fit - the language support between Moodle and TinyMCE is one of those areas. It's not something that will be undertaken lightly.
Additionally, we opted for Atto, as it is something developed and maintained in house. Moodle is now in control of its own editor. We can add features without worrying about breaking upstream compatibility. This is a HUGE benefit for Moodle in general, and the Moodle developers specifically.
Remember old HTMLArea - the default editor of moodle 1.X ? When support for HTMLArea was discontinued core developers started to fix editor bugs themselves - first it was easy when moodle supported only IE4-6 and FF2, after 5 years tracker was full of unassigned HTMLArea bugs that nobody wanted to fix - we got Safari, Chrome, Opera, FF3, IE8, IE9,..., mobiles, tablets,...
HTMLArea was a perfect example of code that was written non-modular, non-pluggable, non-changable - and it took 5 years until Petr Skoda finally wrote the new pluggable editor code for moodle 2 that should allow adding any editors (editor plugins) to moodle: the code for CKEditor integration is not similar to TinyMCE 4 integration or TinyMCE 3 integration and TinyMCE 3 does not need to override TinyMCE 3 - right?
We tested optional editors already with moodle 1.6...1.9 period and no matter what method is used it's good to be able to change editors, editor themes, editor skins and editor skin colour variants including icons of editor as a part of each editor skin. Themes can't detect editor skin (or can they?) but themes can be used to set editor skin with some skin switcher or setting (or user preference) - I was using this method with math plugins (and "tinymath editor") in moodle 2.3 until moodle 2.4 moved custom plugins to new folder...
Adding hundreds of css tags to theme css to override some default editor css settings is like overriding yui css with base theme css and custom theme css.
It would be so much easier to just select themes, select editors, select editor skins and other editor settings from administration menu or even user preferences. The only problem here seems to be custom plugins that don't use similar html/css as core plugins. When you have selected a skin called "moodle" core plugins create html like
<span class="mceIcon mce_numlist"></span>
and skin moodle ui css has code like
.moodleSkin span.mce_numlist {background:url(img/numbered_list.png) 2px 2px no-repeat;}
Customized Moodle plugins on the other hand create html like
<span class="mceIcon mce_moodleemoticon">
<img class="mceIcon" alt="Insert emoticon" src="http://xxx/lib/editor/tinymce/plugins/loader.php/moodleemoticon/2013050100/img/moodleemoticon.png"></img>
</span>
and load a png image from custom plugin tinymce/img folder
Now this can be changed if a user knows what files to replace, images to hide or css to override - and it is just the typical way to change things in moodle.
If nobody else wants to test integration of TinyMCE 4 to moodle 2.5 or 2.6 I could try it next week - as an optional editor plugin - with selectable TinyMCE 4 skins that can be tested with http://skin.tinymce.com/
Mauno, I've already said else where:
To replace the images in the TinyMCE editor is simple - the default icons are loaded as backgrounds -- I've just finished my third deployment in the trenches of TinyMCE, so I have a fresh view on this -- you can set the background of any toolbar button with:
.moodleSkin span.mce_bold {background:url(img/bold.png) center center no-repeat; }
Where the image path is relative to your theme's css file. For TinyMCE plugins, you first need to hide the IMG in the plugin, then set a background for the contain anchor tag.
Surely themers are familiar enough with CSS to handle this in their own themes.
Creating a contrib plugin for TinyMCE4 would be a great step towards getting it ready for possible integration in core. I can't say for sure if it will ever happen - Atto is looking pretty decent, and does most of what we need it to now, so I can't really see us bringing in a 3rd party editor into core to replace our own, custom built, community controlled editor, but crazier things have happened...
Yes themers can handle this in their own themes - although the complication of dealing with TinyMCE plugins may throw people. but I presume your code example should really read
.moodleSkin span.mce_bold {background:url([[pix:theme|img/bold.png]]) center center no-repeat; }
when in the css of a moodle theme?
But if we're going to go down the monochrome route anyway - why not make use of an icon font - such as font-awesome as is being used successfully in many of the newer themes? Much easier for themers to change as required I would have thought.
As for the possibility of TinyMCE4 not making it into core because we have Atto - have you read back over these threads? There is a wide agreement that while there may well be a need for a slimmed down lightweight editor, there is also a great demand for a full featured tool - are you saying that Moodle is going to go down the road of a slimmed down one accompanied by an outdated version of TinyMCE into the future with no thought of updating it? Because that is what your comment seems to be implying.
As good as you say Atto is looking, personally I strongly believe the teams efforts would have been better spent in getting TinyMCE4 into core and not developing a separate inhouse editor from scratch - my 2c!
Please do NOT leave us with an editor which is only suitable for forum posts and the like and makes content creation a web-developer field by requiring a knowledge of markup to generate anything more than the most basic content.
This discussion has been had on these forums and resulted in the community consensus that there is a need for both (unless you are going to ignore that consensus Jason and just plough ahead solely with Atto?) - and surely if that need is there, moodle should have the best of both - which will mean getting TinyMCE4 sorted out for Moodle core.
As for it being crazy to replace 'our own, custom built, community (by which you actually mean HQ as most of the comments from the community relate to getting TinyMCE4 into core not a brand new editor) controlled editor' - well I'd refer you to Mauno's post about the old HTMLArea!! Beside's no-one is suggesting replacing - the comments are all that the choice is needed!
well, yes, the code I grabbed was out of the TinyMCE css, which doesn't support pix at all.
I'm not against font based graphics - I would love to see them used everywhere, they are powerfully customizable. At HQ we work a different way to the rest of the community, and getting these things done - swapping TinyMCE3 for TinyMCE4, getting all the SVG and PNG icons swapped for fonts, etc - takes longer than our allocated 3 week sprints, so these decisions need to be made in advance by Martin, so we can start work on them.
I'm not making the decisions here. I was the HQ dev that tried to get TinyMCE4 in to 2.6 (https://tracker.moodle.org/browse/MDL-40421) - I met with opposition from all sides when I did (mostly discussed in SCRUM and planning meetings, and not on the tracker). My compromise was to make TinyMCE3 look like TinyMCE4, with the hopes of reducing the shock that could be caused by a swap in the future. I would like to see TinyMCE4 as the replacement for TinyMCE3, but I would also like to see Atto developed to the point we don't need another editor at all.
As for community consensus, that's the beauty of the moodle community. Just because it isn't in core, doesn't mean you can't have it. You could develop TinyMCE4 as a CONTRIB plugin, then when it is mature enough, get it integrated in to core - this is how Atto started out, and we've rushed Atto in to cover off some problems with iOS devices. We can't do the same for TinyMCE, because of the way it handle languages - it's been mentioned before, the road to integrating TinyMCE4 is a long one, and would probably take longer than a single release cycle, so we will need to start the process by developing a contrib plugin, then integrating it in to the core.
Now, I personally won't be doing that. I only get 1 week in 7 to work on personal moodle projects, which TinyMCE4 would fall in to, and the other 6 weeks are spent working on issues Martin deems important to the future of Moodle. If I were to start the CONTRIB plugin for TinyMCE4 I would be doing it in my own time, and I really try to avoid taking my work home with me.
So I'm not saying TinyMCE4 will never happen, I'm just saying HQ have been told there is a process that will be followed if it is to make it in, and that process is to prove it works as a CONTRIB plugin, then integrate it in to core.
It looks like I could have a functional TinyMCE 4 plugin available next week. I have been testing the files with two methods - normal editor plugin tiny4 with editor css and fonts in theme (Essential) in 2.5.2 and normal 2.6 editor plugin tiny4 with styles.css and fonts folder in tiny4 plugin folder (the 2.6 method Mary and Gareth introduced in other post http://docs.moodle.org/dev/Themes_overview#Adding_custom_fonts ).
There was one strange BIG issue at start - I hope someone could explain this - moodle did not load original /lib/javascript.php/1381343550/lib/editor/tiny4/tiny_mce/4.0.7/skins/lightgray/skin.min.css because MIME-type of that file is text/html and not text/css - but the original skin css file IS normal css file!!! So this must have something to do with cache methods of moodle?
That's why I used the 2 workarounds for starters.
Adding language support etc really is a large task but since we already have tinymce 3 as a model it should not be impossible to clone to Tiny4 - I have not yet had time to test it but as I said before I have more time next week to try all the settings.
That's great Mauno - my coding skills may not be up to creating such a plugin but Id be more than happy to help test or anything else you need!
Consider me in for testing as well!
Julian
I am very interested to learn about the features that would cause a break in upstream compatibility with TinyMCE. Creating a new editor doesn't actually solve those problems unless you also intend to make it the default... is that the case?
This is really cool! It sounds like we have a consensus
lightweight inline textarea with media (including image) insertion, autolink/link making button, simple attachment tool.
as Amy points out this should obviously clean crudy data on paste, but preserve semantic structure.
as Gareth has pointed out its important this inherits style, so wysiwyg
Semantics for those that want/understand them :
the simple editor could include an action for adding strong, emphasis, lists and blockquotes (possibly headings).
basically, like all the screenshots in this thread.
a link to use a full tinymce 4/whatever WYSIWYG editor full screen content creation interface, moodle filepicker thing etc etc etc...
(we should probably not call the actual link all the jazz
I'd be happy to sign my name to that as a spec
Is that what we want/need?
By George I think we've got it Stuart!!! :D
A lighter editor, with the easy availability of the additional tools where needed.
For me, exactly what buttons/tools are available might be something for the admin to set (e.g. some may want the preset styles/headings, others may want the blockquotes, some may want both) - maybe a similar admin tool to the current TinyMCE one, but with the more limited selection of options to be available in the lighter editor. Or maybe it'll be light enough to cope with having one or two additional tools, so long as that doesn't feature-creep back to the 20-30 in the full editor
To my mind - TinyMCE4 with the PWD plugin (that allows a slimmed down tool set and a full set to be toggled) and the admin/config tool we have now for Tiny3 would probably cover most of this,but I can see the benefits of a separate editor which is just lighter altogether and the option of choosing which is the default for your site/user. I can also see that this isn't going to happen for 2.6, but maybe TinyMCE4 for 2.7 - or someone to work on it as a downloadable plugin in the meantime
Richard
Have you tried Moodle 2.6 yet?
All editors now initially appear one one line of the most basic tools, with a button to click if you want to everything else.
Look for the July screen-grabs on MDL-37565:
Would be good to upgrade to TinyMCE 4, but probably prudent to wait until Moodle 2.7 for that.
thanks so much for posting this tim,
just tried, and as your screenshots above show it is so much better!
i'm still having issues with speed of the tinymce in moodle, getting it working on mobile, accessibility compared to vs4 and some of the other issues in these various threads about the wysiwyg editor but really excited to see moodle hq taking tiny steps in the direction of usability
fingers crossed tinymce4 will mitigate these issues for m2.7!
thanks again for the heads up.
cheers
stuart
Thanks Tim - no I hadn't seen that in 2.6 yet, but looks pretty much what I did (with Mauno's help) in my 2.5 TinyMCE a while back Its a great addition to the tool set!
Tim,
following your advice I decided to try moodle 2.6 test install and what did I see - a minimalist tinymce3 skin (called moodle)
I know I am too old to understand minimalistic art and design but I liked (and miss) the colors in buttons - especially because that dragmath button 
was one of my rare "contributions" to moodleland
Now I wanted to change the old tinymce 3 skin back and added to Site administration > Plugins > Text editors > TinyMCE HTML editor > General settings > Custom configuration
{"skin" : "o2k7","skin_variant" : "silver"}
but all moodle 2.6 custom plugins seem to be using new "modern style icons" - and a little blurred
These modern, minimalistic icons look pretty similar to some old C64/Atari/Windows 1.0 - style icons : http://psd.tutsplus.com/articles/theory/know-your-icons-part-1-a-brief-history-of-computer-icons/
so our production site is going to stay in moodle 2.5 for a while...
( image from http://understandingminimalism.com/the-difference-between-minimalism-and-simplicity/ )
Each editor can have custom skins - but why should TinyMCE 3 look exactly like Atto?
+1 Mauno
Please can we have the option at least of a coloured icon set. What with the influx of font based icons everything seems to be going so monochromatic! Yes I know font-icons can be coloured as any other text - one colour as far as any I've seen though.
Medium grey on pale grey, with washed-out grey for inactive icons just seems so... well, grey!
As ever, a Moodle theme can replace any image used anywhere in Moodle.
Tim, Just to confirm what I think you are saying.
Can a theme replace the icons being used in the editor?
If so, what is the directory structure that these images would need t be placed in.
Julian
To replace the images in the TinyMCE editor is simple - the default icons are loaded as backgrounds -- I've just finished my third deployment in the trenches of TinyMCE, so I have a fresh view on this -- you can set the background of any toolbar button with:
.moodleSkin span.mce_bold {background:url(img/bold.png) center center no-repeat; }
Where the image path is relative to your theme's css file. For TinyMCE plugins, you first need to hide the IMG in the plugin, then set a background for the contain anchor tag.
Thanks Jason!
Interesting Damyon - but..
First sentence on that Moodle icons link
Not only are the new icons a little bigger and more colourful
Really? colourful?
And forgive me for saying, but in those screenshots the background of the buttons is not white - they are grey on grey - so how does that help the contrast for accessibility? I'm not partially sighted, but the icon for highlighting/background colour and the little t and w in the paste icons - well, maybe its the sceenshot quality, but they really are not easy to see (for me).
Right now, for me, one of the first things I change in my theme is those grey icons - I guess I'll have to look into how to do that for TinyMCE as well from now on (edit: Just seen Jasons post above - thanks Jason!). I hope they can be changed directly in the theme, or are we going to have to create a separate TinyMCE theme and install it into the TinyMCE folder somewhere? Consistency doesn't have to mean monochrome! The guidelines you pointed to have a colour palette and style guide which can be used for consistency which would not mean turning everything grey-on-grey!
I do realise that is just my own opinion and maybe goes against what others think - I just hope we have the flexibility to restyle it easily for those like me who want a bit of colour in our lives
Richard
This is what the editor will look like (this is still a WiP, and has many rough edges) as you can see we have shifted from the grey on grey.
Also, the designer that created these buttons is the same one that wrote the moodle style guide.
Hi Mauno,
The tutsplus is an interesting article, although it is mainly Microsoft and Apple and as somebody has commented does not cover Unix / Linux in terms of X-Windows etc. Or indeed the influence of Silicon Graphics.
I Googled and found part two: http://psd.tutsplus.com/articles/theory/know-your-icons-part-2-modern-icon-design/
Cheers,
Gareth
We aren't just making TinyMCE look the same as Atto. The path we followed when developing these themes etc was:
As you can see it's not just a case of make all the editors the same. It's about providing a standardised and familiar UI across Moodle, something we have lacked for a long time now.
We currently have this, with TinyMCE3 being the All the Jazz, and Atto being the lite version ... the new user preference will allow users to pick the editor they need too.
It's a work in progress, and still has a lot of rough edges, but this is what the new TinyMCE theme looks like at the present.
Looks much better than yesterday (after the first shock) with some borders and grouping 
Are mobiles or small screen devices using the same scale or is this a zoomed screenshot?
That's it at full size, no zoom. We are using one size for all screen types, with the intent of making it consistent and touch screen friendly.
Although it's certainly better than the grey icons sitting on a grey background, the fact that the icons are still grey makes my brain see them all as being disabled. If I look more closely, I then start to notice the even lighter grey icons and wonder whether they're all disabled or just the lighter ones, but there's not enough visual difference to immediately tell "that's disabled" vs "that's enabled".
If it's not already on the cards, I'd suggest making the "enabled" state substantially darker - and increasing the contrast in the "background colour" (at least, I assume that's what it is) button would also be helpful, as at a glance it looks like a box with feet. The TinyMCE4 basic demo uses much darker icons (though still not black - but close enough that they stand out as being active). In fact, the TinyMCE4 demo's "disabled" state is virtually indistinguishable from the "enabled" state in your screenshots!
Paul, that "box with feet" for the font highlight button is a background that changes colour along with the choices that the user makes. So if the font has a red highlight, the background will be red.
Ah. The "A" should probably have a border, then, so it stands out against similar colours - otherwise somebody could choose the exact same colour and it'd actually become a box wit feet! (Unless the "A" automatically changes colour if the BG colour gets close enough, in which case that "close enough" determination needs to be tweaked...)
Ah, great suggestion, I will talk to the designer about it, and get that sorted!
Paul, after your suggestion about the box with feet, we went back and had a look at it, and this is what we have now. Most of the rough edges have been smoothed over, and it is looking pretty consistent with the rest of the Toolbar UI.
Hi Jason,
That looks better. I still think that the icons are too light, though - even with some disabled icons in the mix (such as "redo" and the link-related icons), my brain initially sees all of the icons as being disabled (the ones which actually are disabled are so light that they almost disappear entirely). Making them darker might also help prevent the coloured triangles in the font/bg colour icons from standing out so much - at the moment, being the only colour in a sea of grey makes them stick out (though if they still reflect the current colour choices, I imagine it wouldn't be quite so bad if you have it set for black text on a white background).
I agree. I was testing today customised moodle plugins (tinymce 3) in tinymce 4 with compat3x plugin and that tiny difference between icon fonts and gray png images is visible in attached toolbar
TinyMCE 4 skins made with skin creator work ok in my test install but unfortunately all those custom moodle plugins must be converted to TinyMCE 4 API - none of them was fully functional with compatibility files for the old 3.x branch (compat3x).
I have to agree that in my mind (and in UX in general) gray = disabled. That said, it does look a bit like the gmail signature editor, but that has increased contrast, and 'button' on hover.
guess which one I'm hovering ;)
We have a hover effect on all our toolbar buttons now, it's currently awaiting integration for atto https://tracker.moodle.org/browse/MDL-42091
here is a quick method for designing ui for content input elements :
1. Content audit
for this you could sample the content in a course label, or in web pages or forums.
for 30 inputs i found the following content :
video
link
text
text
text
text
text with link
text with link
text
text
mp3
mp3
text
link
text with image
text
text
video
video
text
text with link
video
image
link
text with link
text
text
image
text
text
text is the most frequent with 50% of content containing purely text
7 - contained links
4 - video
3 - images
2 - mp3
From this sample only 1 text contained any semantic markup such as headings, italic, bold, blockquotes or lists.
You could repeat this on a course such as the one on learn.moodle.net and see what you get!
This would suggest the most frequent task is adding text, with links, video/images and audio as the other tasks users need as standard.
With the clear option to use the kitchen sink editor for those that need it.
Hi Stuart,
I have not been following this discussion as I find it too techy for want of a better label. But what you are saying here, if I have this correct that is, that Text editors should be simple to use with only the minimum of options. I would agree with that whole heartedly.
Forums only need those options you mention. Other areas like courses could uses other simple option types pertinent to their subject matter.
Cheers
Mary
Stuart,
nothing wrong with this kind of "editor theme switcher" - if you google some old editor posts from years 2007 to 2011 in editor/developer forums we were discussing and testing not only user preferences but also role based, activity based, course based and theme based editors and editor switchers.
We had different reasons for testing these switchers and plugins: some people wanted simple editors with a couple big buttons and some plugins for young kids. Storytelling module had role based buttons but the toolbar skin itself was using small buttons. Some people wanted to add maths and graphs to their courses and because HTML does not support mathematical notations, you had to use either non-editable images, mathml or latex and different scripts for graphs. Tex filter was not user friendly enough. Using latex or mathml is just as "easy" as using HTML source or javascript
Some people wanted to have unicode character plugins or virtual keyboard plugins (core plugin has only a few characters) etc. Or easy tools for adding image maps, recording audio online (Nanokong, PooDLL,...)
Each site can have custom needs and each site can change custom settings - and default theme for simple "editor" could use totally different editor theme (if wanted).
Usually the user input is not plain text anyway - it's HTML - so "text" has also HTML tags like <br> or <p>
In moodle 2.5 one of the new features was collapsable and expandable editing tools
Isn't this the most simple tool for your needs (students writing plain text) - it is more advanced than plain textarea and allows also switching editing tools on.
Note however: once the default setting was turned to "collapsed" some moodlers were demanding it to be set "expanded"
In fact this could be done with tinymce 3 too - it has only two core themes "advanced" and "simple" but you could write new editor themes to tinymce 3... and tinymce 4. Ribbon theme http://tinymce.swis.nl/demo was just one example.
Or one could create a more advanced pdw-plugin ( that "kitchen sink-button" ) - current plugin just toggles toolbars (show/hide) but it could use more css to change default layout of editor.
In editor themes you can literally change everything that tinymce outputs http://www.tinymce.com/wiki.php/TinyMCE3x:Creating_a_theme and skins are mostly for tiny css changes http://www.tinymce.com/wiki.php/TinyMCE3x:Creating_a_skin
The main difference between tinymce 3 skins and tinymce 4 skins is that tinymce 4 skins use web fonts and less files css http://www.tinymce.com/wiki.php/Tutorials:Creating_a_skin
The javascripts of tinymce are just like the motor of a car and with javascripts and css (car body) you can create both nice and simple basic tools or more advanced tools
1885-built Benz Patent-Motorwagen, the first car to go into production with an internal combustion engine
Lexus LS-460
Stuart, that's pretty much what is ALREADY in place, as Tim demonstrated with his previous post.
There is a plain text editor box in which the usual keyboard short cut keys for things like bold and italic work. You 'Show Tools' to get a simple first line set of tools. You click the PWD icon to reveal a full set of tools.
Its there, its happening, it provides the simple (or no) tools editor you are looking for, with the powerful tools easily accessible for those that need them.
I really am getting lost in exactly what else it is you want other than to prove a point that has already been accepted over and over and over again.
Yes we need a simple tool set - but we also need the power tools when and where they are needed - this has been accepted and agreed again and again, but you keep going back to the same point repeatedly without actually contributing anything new to the debate. We all know that you feel that YOUR users dont use anything except the most basic tools, you've told us so often - I could do exactly the same exercise you have just done on a Primary school website and come up with the results that the majority of the content sections use highly formatted text, colours, sizing, images, embedded videos and so on, even tables (yes used appropriately for tables of information or science experiment results!). It proves very little beyond the points which have already been agreed in the discussion ie. that some people dont need all the tools and others do, so give them the choice!
Usually in a debate, once a point has been made and accepted by all parties, there is a negative effect on your argument if you continue trying to hammer it home - it is that effect on this debate that is referred to in comments that have been made about your posts not being helpful to that constructive debate.
Apologies if this has been discussed already, but unless your theme contains a stylesheet called editor.css then no matter what you type YUI CSS will style it differently.
Talking of text editors, something not fixed yet in Moodle, is that when setting data in a table with borders using TinyMCE, none of the table borders are shown after saving.
Cheers
Mary
Apologies also if this has been discussed.
Is drag and drop for images a possibility in the editors you are discussing?
This is one of the final functionalities needed to speed the quick creation of things like labels, pages and section descriptions. Not to mention posts.
-Derek
Hi Derek,
this was discussed a lot last year at moodlemoot in uk.
drag n drop as implemented in moodle currently creates separate assets - labels, attachments ect in a list - like a document management system.
In most systems the drag n drop puts the assets into the content your creating in the editor, which i believe is more appropriate for moodle.
We did a demo of this at the moot which seemed to go down quite well - our tutors also loved it.
certainly a feature i'd vote for.
cheers
stuart
