TinyMCE 4 and default toolbar

145 views
Skip to first unread message

Uncle Cheese

unread,
Jul 6, 2014, 6:39:23 PM7/6/14
to silverst...@googlegroups.com
It looks like there's been some substantial progress on the effort to get TinyMCE 4 integrated into SS3, which is fantastic news. I'm wondering if we might also use this opportunity to reduce, drastically, the inventory of buttons in the toolbar that the default instance of HTMLEditorField gives you. For as long as I can remember, SilverStripe has thrown you the kitchen sink TinyMCE installation, sending users on a time warp to MS Word 2000 and overwhelming them with way too many options, more opportunities to break stuff, and a slower editor to boot.

Yes, there's an API for it, and I always make a point to create my own settings, but it seems like unnecessary boilerplate to me. The default case should not be the edge case. Tables, horizontal rules, and the seemingly redundant "cut and paste" options are decidedly an edge case IMO.

My ideal default TinyMCE would look a lot like the editor I'm typing into right now on Google.:

Paragraph/Heading, Bold, Italic, Link, Image, Media, lists, block quote, alignment.

What does everyone else think? 


Nitish Prakash

unread,
Jul 6, 2014, 7:06:52 PM7/6/14
to silverst...@googlegroups.com
Hello to all,

While I have vowed to myself as a dev to create my own things, not only because I can, but also to learn more, I dropped using wordpress as my main blog platform. But I do have to say I've enjoyed just how much detail wordpress had always included in their TinyMCE Editor implementation. It was never overpowering to the point where it felt like I was working on MS 2003, 2007 etc with the ribbon interface of unorganized mess everywhere; icons galore.

However, having looked through some other plugins for wordpress I came across TinyMCE Advanced which included drop down menus; Files, Insert, Edit etc. as if working on a standalone program. Below those menus were the simple default icons always included for quick editing, mostly the most used icons (bold, italics, quotes etc).

http://premium.wpmudev.org/blog/wp-content/uploads/2014/05/tinymce-advanced.png - this might show more detail then I spoke of, but it was to get an idea of the drop down menus, and how much cleaner and nicer it might be.

I can also agree to an ideal editor consisting of only what Google has to show. It is simple, and yet so much can be done with the simple most used functions. My ideal editor would include the advanced TinyMCE options of the drop down menus and the simple google layout as well. One thing I know I always become slightly not used to is how many users who don't know the keyboard shortcuts for the simple most used functions that do work without the need for an icon for it, but having an icon for those functions would help them immensely. (They should also spend some time to learn the short cuts if they use it a lot, but that is another can of worms regarding 'users')

I know I'm playing devils advocate here and trying to have reasons for both sides, if only to ensure that every possibility was thought of before making a decision.

If the API for it exists and we can always include the icons/functions needed based on the use case scenario, then during a default and base install of SS, the least amount of inclusions would be best overall, for performance(my obsession) and usability regarding the user.

I hope my thoughts can help here.


--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.



--
Nitish Prakash
Developer /  Designer / Ninja
021 151 6867

 - "Everything in Life, but Life itself, is expendable."

Zenmonkey

unread,
Jul 6, 2014, 8:51:04 PM7/6/14
to silverst...@googlegroups.com
I have to agree with Uncle Cheese, the default SS TInyMCE editor is a beast and just creates problems for the average user. I know a lot of peope would like to just drop TinyMCE, but know it's not really an option at this point. I would like to see it stripped back bare bones.

Aaron Carlino

unread,
Jul 6, 2014, 8:55:28 PM7/6/14
to silverst...@googlegroups.com
… and to be clear, I have no issues with using TinyMCE as an editor. I think it’s extensible, stable, and has a big enough install base to justify its inclusion in the CMS. I’ve just seen much more elegant adaptions in other products.

I don’t have any data to support this, but I strongly suspect most users spend more time in the wysiwyg editor than anywhere else, so it’s not an integration point we should take lightly.

Cheers,
Aaron

--
You received this message because you are subscribed to a topic in the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/silverstripe-dev/XnXhwxKw7V8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to silverstripe-d...@googlegroups.com.

Szabesz

unread,
Jul 7, 2014, 1:23:14 AM7/7/14
to silverst...@googlegroups.com
+1
:)

Nicolaas Thiemen Francken - Sunny Side Up

unread,
Jul 7, 2014, 6:49:16 AM7/7/14
to silverstripe-dev
+1

Shaun de Greeff

unread,
Jul 7, 2014, 8:53:48 AM7/7/14
to silverst...@googlegroups.com

+1 ...i would just add the following to the list:

 

·         Indent increase / decrease (i use that a lot in lists)

·         HTML view (still handy to be able to get to code)

--

You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.

Roman

unread,
Jul 7, 2014, 9:14:10 AM7/7/14
to silverst...@googlegroups.com
I'm also in favor of an uncluttered TinyMCE installation, but I'm also quite certain that there's no default-set that will contain everybody's requirements.
As an example: I rarely use "Media", because most of the time I provide special editor fields for this. I even tend to remove the "Italic" button in projects where there's simply no need for italic text.

Configuring the buttons via .yml config files would be nice, because currently the `HtmlEditorConfig->setButtonsForLine` directives is almost the only config-code that still sits in my `_config.php`.

So yeah, uncluttering the UI for default installations would be nice, but IMHO it's more important to have an easy and flexible way to define the TinyMCE buttons on a per-project basis. The one good thing about the large button-inventory of the default installation is, that you can easily look up a lot of the existing buttons in code.. or just copy-paste the arrays from `HtmlEditorConfig` and remove the buttons you don't need...

swaiba

unread,
Jul 7, 2014, 11:11:25 AM7/7/14
to silverst...@googlegroups.com
+1  TinyMCE v4 looks much better
 

Sigurd Magnusson

unread,
Jul 7, 2014, 3:40:36 PM7/7/14
to silverst...@googlegroups.com
I'm all for decluttering; by my definition meaning that moderately used items need to be tucked away but available in GUI and rarely used can be enabled via developer configuration.

Sigurd
--


On 8/07/2014, at 3:11 am, swaiba <ba...@bookinglive.com> wrote:

+1  TinyMCE v4 looks much better
 

--

Fred Condo

unread,
Jul 7, 2014, 5:06:01 PM7/7/14
to silverst...@googlegroups.com

> On 8/07/2014, at 3:11 am, swaiba <ba...@bookinglive.com> wrote:
>
>> +1 TinyMCE v4 looks much better
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
>> To post to this group, send email to silverst...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/silverstripe-dev.
>> For more options, visit https://groups.google.com/d/optout.
>

On Jul 7, 2014, at 12:40, Sigurd Magnusson <sig...@silverstripe.com> wrote:

> I’m all for decluttering; by my definition meaning that moderately used items need to be tucked away but available in GUI and rarely used can be enabled via developer configuration.

In a perfect world, the editor implementation would have a layer of abstraction enabling us to rapidly switch among various editors or even a plain-text Markdown or SEtext implementation. Right now it’s all much too tightly coupled.


Aaron Carlino

unread,
Jul 7, 2014, 5:55:45 PM7/7/14
to silverst...@googlegroups.com
@Roman - You’re totally right that we can never make everyone happy, and that’s why it’s of paramount importance that the HTMLEditor remain easily, and inexpensively, configurable. But with the default configuration, we need to pitch straight down the middle to make as many users as possible comfortable, because there so many cases where the developer either isn’t skilled enough to update the editor, or he just forgets, or he doesn’t even know the API exists, and users get this obtuse editor that scares them away from SilverStripe. 

I actually think the conversation about what buttons should “make the cut” is ancillary to just making some commitment to reduce their volume significantly. The users who are turned off by too many buttons are far more populous than those who will be let down when they see they need to make an API call to add tables to the wysiwyg editor.


Cheers,
Aaron

You received this message because you are subscribed to a topic in the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and all its topics, send an email to silverstripe-d...@googlegroups.com.

Florian Thoma

unread,
Jul 8, 2014, 9:19:17 PM7/8/14
to silverst...@googlegroups.com
I think de-cluttering the interface would definitely be beneficial.

Although I would probably propose something similar to what wordpress does with the toggle button for the kitchen sink.

Also, there could be some predefined configs with different buttons, similar to the GridFieldConfig and subclasses. And that config class could be set in the yml config.

Shaun de Greeff

unread,
Jul 9, 2014, 3:45:34 AM7/9/14
to silverst...@googlegroups.com

"Although I would probably propose something similar to what wordpress does with the toggle button for the kitchen sink"      +1

--

Reply all
Reply to author
Forward
0 new messages