Editor Feedback

[Lindy]

You've spoken and we are listening. It's clear there are concerns with the changes made to the editor in 3.4 and we are here to help.

As there is a vast amount of feedback spread throughout the forums, I would like to elicit consolidated feedback from you. Management will be meeting with the development team this coming week to work on a revised plan for 3.4.2 to accommodate as much feedback as possible.

What we need at this point is constructive, actionable feedback. It is not necessary to delve into bugs in this topic, we will address those via the bug tracker. This topic is primarily to address usability and user experience issues.

With that said, there will definitely be improvements to the code and quote functions to address concerns such as multi-quoting, split quotes, etc. We all agree this is necessary.

Please keep this constructive. :smile:

Thanks for your help!

[mat206]

When I saw you guys were going to start storing more fully parsed versions of posts in the database I knew we were in for a world of hurt. Here are some suggestions since it's clear this editor has been giving you guys a ton of headaches:

• BBCode is still very useful in allowing users to post things that would otherwise require complex HTML - It also gives us as bbcode creators uniform control of the output. We as a community see that slipping away and it's scary.. more because our communities have come to rely on it.
• CKEditor is barely used as a WYSIWYG editor relative to it's capabilities - the html purifier filter is good, but allow US the flexibility to whitelist tags as well. With purifier now in place you are creating a situation where we can control on a fine-grained level what is allowed to be posted.
• I'd love to be able to turn on other CKEditor features and know they would work - editing tables would be pretty awesome
• The current editor development is becoming so rigidly entrenched in all sorts of custom modifications for the purpose of this software that we as users are losing our own flexibility. For developers it's looking increasingly more like the entire ball for what we can actually do with the editor is in your court.
• Keep BBCODE but try this approach. Make the editor pluggable so we as developers can create alternatives. As long as it can display basic html that's all you need. If it's a plaintext editor show that stuff in the editor in the whitelisted HTML format. If it creates HTML so be it, if it creates BBCode so be it.. but please never ever translate what the user types into the editor when it comes time to edit their post. If I type bbcodes for bold, I should darn well see the bold bbcode tags when I edit it again. When I hard code a source tag, I should still see that later. From that perspective, you should just worry about using HTML purifier and your bbcode parser and be as editor agnostic as possible. SOO much work was created when you try to translate bbcode into HTML and back.. and it ticks people off because it loses what they originally created.
• Make the editor pluggable - NOBODY on my site even wants a WYSIWYG editor since they don't work that well for programmers posting code. This is probably why sites like Stackoverflow use Markdown (kind of like a bbcode variant) instead.

I honestly think you guys have tried to do so much with CKEditor that you turned the process into a nightmare.. and slashing bbcode is the easy way out. Create an editor plugin setup that consists of a class to show the editor, load it, etc. and an accompanying class to parse the input that comes from using that editor. The developer controls BOTH. We as developers should be able to use a standard text processing library to handle what the user types into the editor. And again, never ever ever change what the the user typed in when saving to the database. The rendered versions of posts should be cached.. disk space is cheap these days.

[Loren]

The WYSIWYG editor has made great advances in the past few years. You folks have done a great job of getting us lots of great features.

- I think the editor needs to work the same (at least to the end user) in all the Suite apps - especially IP.Content. Inconsistent operation drives users crazy (as well as admins).

- For those will special needs - allow compatible plug-ins. Not everyone wants or needs some plug-ins -- so make them option if you can. (for example unlike the previous poster no one on any of my 3 site has ever used the programmers BBcode except in error).

- I think the toughest thing is likely converting old posts, articles, comments, etc. I have one site that is ten years old and formatting from older posts gets whacked when editing (i.e. updating tutorials). If you can create a tool that can run a good clean-up that would be great.

Thanks for all the great work so far!

[mat206]

- I think the toughest thing is likely converting old posts, articles, comments, etc. I have one site that is ten years old and formatting from older posts gets whacked when editing (i.e. updating tutorials). If you can create a tool that can run a good clean-up.

My article editor has nightmares about this.. over 2,000 articles that they can never go back to edit because they know whatever the newest editor is is going to destroy them.

[Cap'n Refsmmat]

I need a simple way to write custom BBCodes that require PHP logic. The current documentation basically tells me to write a regular expression to find my BBCode tags and replace them, while IPB's built-in BBCodes use a much more careful parser that follows all sorts of strict rules. I need to hook into that parser and use it directly. I also need a way for my custom BBCodes to work with the new editor. Currently, if I type them manually I find the closing tag gets eaten half the time at random. Haven't figured it out.

(Also, it's very frustrating to write a BBCode plugin and find that <, > and other symbols have already been processed into HTML entities -- I'm trying to parse LaTeX math, and so I have to undo all of that.)

I also suspect a lot of people would appreciate a plain non-WYSIWYG editor where the toolbar buttons are still available to insert BBCode tags. I would switch over to it as default on my forums.

[Jυra]

1. Revert the change to quotes. They're way too tricky to manage when making a post...or do #2.
2. Make it so the visual editor can be disabled, hidden, and/or made as not default.
3. Make it easy to add/remove BBcode buttons and drop down menus. IPB's old editor was easier to find stuff to pick out for removal.
4. Buttons usable in non-visual editor mode.

I don't care if it's BBcode or HTML, as both are common.

[Kandice]

I would be happy if I don't have to keep pressing the Light Switch back and fourth every time I want to write my BBCode, edit my Code and Quote, paste Texts, etc. One example is that if I want to add more text in the code and quote, I have to press the light switch because pressing return it go outside of it.

I also want the RTE tot he way it was in 3.3, in 3.4 all Text that I copy loose all format and turn into plain text. Nothing look right when I copy and paste in 3.4.

[Traaginen]

I personally don't understand all of this love for BB code. I'm for dropping it sooner rather than later and completely switching to CKEditor (html) as it was meant to be. Yes, there is going to be difficulty in converting old posts, but honestly this is going to happen one way or another eventually. Putting it off is just going to result in more skewed content down the road. A more standard implementation of CKEditor would solve literally every functionality complaint I've ever had; many of the features that are hacked out of the current editor (tables, image wrapping, etc) are absolutely necessary for high-quality content creation, especially in IP Content.

The people who are really pro-BBcode editing, from what I've seen, primarily use it to troubleshoot current shortcomings in the RTE. They're experienced users who probably know HTML or can at least apply the same concepts. Editing CKE's HTML source, <i> instead of , isn't going to slow them down. Not to mention they'll probably have fewer things to "fix" without all of the conversions happening in the background. I may be wrong, but it seems like a lot of the demand for a return of the old BBCode editing mode stems from issues that wouldn't exist with vanilla CKE.

As administrators we should be asking "What's best for my users?" The vast majority of average users don't use BBCode at all. I'd rather supply a fully featured, bug-free WYSIWYG instead of adding development time to an antiquated, non-standardized mark up.

tl;dr or if none of the above is practical, my main issue with the current editor, as it stands, is the severe limitations on features already included in CKE. I shouldn't need a mod to wrap text around images in something like Content that's supposed to hold articles.

[Lindy]

Thank you for the feedback thus far and we're especially glad to see your thoughts on BBCode. It is indeed the crutch of the editor quirks and issues and will undoubtedly need to be phased out as we move forward with modernization to take full advantage of CKEditor.

As mentioned, we recognize that the quote and code are the largest concerns right now and we will be addressing that in the next release.

Thanks again.

[Ryan H.]

Personally, I like the quote changes in 3.4... spacing is just a little quirky, and it would be helpful to see what name is attached to each quote box.

On the whole, I agree with Traaginen.

[Bob van Leeuwen]

I don't now if it already has been mentioned ore not. But if I desable the WYSIWYG function, I can't click on the buttons anymore. I would like to see this added back.

[Rimi]

I guess most of what I want has been voiced...all I really want to add is that IPS should stop trying to dumb everything down. Yes, you have power users. Yes, you have casual users. But you shouldn't burden the power users in favor of supporting the casual users. You should be supporting all modes of content submission. This means that if I want to manually type in code tags into the ckeditor, then it should work.

[mat206]

As administrators we should be asking "What's best for my users?" The vast majority of average users don't use BBCode at all. I'd rather supply a fully featured, bug-free WYSIWYG instead of adding development time to an antiquated, non-standardized mark up.

What's best for your users isn't what's best for all users. What's best for my users is no WYSIWYG editor at all but that's not an option. There are plenty of LARGE sites out there that rely entirely on bbcode-like markup rather than WYSIWYG. Because, as we often see, what you see is NOT always what you get. Sites that need perfect accuracy in posting use alternatives to html markup. And remember, bbcode expands into more complex html that users shouldn't have to post. Sure, we have a few simple options like bold and italic tags.. but stuff like quotes/code tags are more complex. I also have LaTeX parsers as well for equations which you cannot generate html markup for.

The problem is that bbcode should never be translated when saving posts to the database.

[Lindy]

There are plenty of LARGE sites out there that rely entirely on bbcode-like markup rather than WYSIWYG.

Do you have any examples, just out of sheer curiosity?

[Lewis P]

The problem is that bbcode should never be translated when saving posts to the database.

Not really. As long as it is translated logically and has a guaranteed reversal method, then there is no reason why it can't be saved as parsed content. At the end of the day, as long as a source mode is always available (be that with or without functioning buttons) then the method of saving is irrelevant. ;)

[mat206]

Thank you for the feedback thus far and we're especially glad to see your thoughts on BBCode. It is indeed the crutch of the editor quirks and issues and will undoubtedly need to be phased out as we move forward with modernization to take full advantage of CKEditor.

As mentioned, we recognize that the quote and code are the largest concerns right now and we will be addressing that in the next release.

Thanks again.

BBCode is NOT the problem with the editor. I don't know why you keep saying that. The problem is that Matt decided that he needs to translate bbcode into HTML so that the editor deals with that instead.. and the more he does it, the worse things get because the translations are imperfect.

This is 100% caused by your programmers. The sad thing is is that they had good intentions, and the ideas behind trying to translate all the bbcode into html counterparts seemed to be reasonable. Clearly you could make it work in 3.1, 3.2, 3.3.. and in one version you push things too far and now you want validation that you are doing it right. This *approach* to bbcode doesn't work. Take a step back and get back to simplifying things again. What's ironic is that your idea of a fix is just gutting something that's been part of this software forever just because your experiment to mix the two in the editor failed.

Not really. As long as it is translated logically and has a guaranteed reversal method, then there is no reason why it can't be saved as parsed content. At the end of the day, as long as a source mode is always available (be that with or without functioning buttons) then the method of saving is irrelevant. ;)

Bingo. The problem exists because bbcode's don't have guaranteed reversal methods. This is entirely the problem and the reason why they shouldn't be translated.

[mat206]

Do you have any examples, just out of sheer curiosity?

Sure.. here are some off the top of my head, chosen because they are some of the largest sites on the net.

• Wikipedia
• Reddit
• Stackoverflow

[Lindy]

Mat, it's clear you're a power user and that's great, but unfortunately, you do not represent 95% of IP.Board users who simply want to use a WYSIWYG, click pretty buttons, create their content, make things happen and move on with life. HTML functionality is native to CKEditor (BBCode is NOT) and is needed for various current and future functionality across our platform, including IP.Content. You're right, BBCode and HTML together is proving to be a bit of a failed experiment and that's where we are. Moving forward with HTML while trying to accommodate 1990's technology that a relative few care about anymore is a challenging adventure, but again, we're open to feedback beyond "revert and stifle progress."

The sites you mention, as I suspected, have a very narrow focus that perform a very simplistic function. They don't have to try and be something to everyone across an entire suite of products and with various customizations on different platforms.

[Cap'n Refsmmat]

Kind of funny to say that reddit has "a very narrow focus" when it hosts active and successful communities on many topics, many of which I am envious of. Markdown hardly seems to limit it at all.

So what is the way forward for custom BBCode enhancements in the new editor? Is there a way of extending the editor with new features, or will I just have to give up on LaTeX in future versions?

[Rimi]

Mat, it's clear you're a power user and that's great, but unfortunately, you do not represent 95% of IP.Board users who simply want to use a WYSIWYG

Ah, here it is again.

you shouldn't burden the power users in favor of supporting the casual users. You should be supporting all modes of content submission.

Your mentality is just all wrong and this is where everything is going down the drain and why we are frustrated. I appreciate that you want to move forward, phase out bbcode, and focus on HTML submission. I think it sounds intriguing and could have some very nice benefits. However, IPS needs to appreciate just how difficult it is for us as forum admins to get our users to adapt to the changes you want to make. Our users have been using bbcode for over a decade. Sites like imgur, tinypic, photobucket, and minus spit out bbcode for users to submit to forums. It specifically says on there "Code for forums". This is something universal. I'm not telling you to continue developing on bbcode. I'm not even saying to stick to it. By all means continue on your path for html posts, like I said it sounds intriguing. But this whole "you are a power user so you're wrong" thing needs to stop. You cannot topple a decade old skill in a day.

we're open to feedback beyond "revert and stifle progress."

My feedback to you is just have backwards compatibility. I'm a member of a very large vbulletin forum which recently switched to xenforo, a forum software that doesn't have bbcode. The users there are very confused on how to get the editor working. Some users are saying how they're losing interest in the site because they don't understand how to submit content anymore. Yes, it's a transition process, and with your plans it's one that we will all have to force our users to do, but I think you can make the transition smoother. I suggest that you support bbcode input in 4.0. Convert to html on submission and in the editor keep it as html whether it be ckeditor or standard mode. Like Matt and Marcher keep saying, there is no difference between [ b ] and <b>. If a user can type in [ b ], have it get stored as <b> and later they come to edit their post and see <b> or even <strong> I think they will catch on a lot more quickly, and it will be a lot less painful for everyone, than if you were to just go out and say "Ok guys, from now on you have to type in <b> instead of [ b ]".

[mat206]

Lindy, why can't editing be a simplistic function?

How about this, can you make the editor swappable? If you are going with just html anyway then abstract it in a way where we can choose what editor we want if there are more than one available. That way a third party can put in markdown, bbcode, html, or plaintext or whatever they want in as the editor provided an editor plugin exists for it. Seeing as it is the central input for the whole suite at least that should be reasonable.

We have no way of getting out of this choice.. you are literally *forcing* it down our throats and telling us to be happy about the choice because it will only alienate 5% of your business. And I don't buy the fact that anything but a WYSIWYG editor is accessible to users since billions upon billions of page views are fed to pages not created with any sort of WYSIWYG editor on public sites. Markdown can be used anywhere HTML or bbcode can be used, so it's a weird argument to say that it isn't general purpose. They are all variants for posting the same exact things. Clearly from Wikipedia you see that it can be employed to much success over millions of articles.

Please just give us the ability to *have options*.

Here are some CMS suites with more users than IPB and the editor selections:

Joomla - http://extensions.joomla.org/extensions/edition/editors

Plone - http://plone.org/documentation/kb/content-creation-with-kupu/wysiwyg-editors-in-plone

Drupal - http://drupal.org/node/208456

[Lindy]

We are not saying the current implementation is how it's going to be. :) The future for us, our products, most of our users and some of our competitors is HTML functionality. If you have examples of HTML and bbcode coexisting in a unified editor, I'd welcome you to share for reference. The fact is, the lions share of the issues past and present are due to striking a balance. Again, I welcome examples of those who have achieved the perfect editor using both technologies - we never stop learning. :)

There are options and nothing is completely off the table for 4.0, so keep a positive discussion flowing.

[Lewis P]

There are options and nothing is completely off the table for 4.0, so keep a positive discussion flowing.

I call for a a normal textarea with no flashy toolbars and parses absolutely anything that is put in there. After all, someone might want to post some genuinely useful Javascript.... ;)

To clarify to those who think I'm being serious, this is sarcasm.

[Marcher Technologies]

hrmm.... the thing is Lindy, he just did. 3 arguable competitors to Content are handling it fine.

Not just bbcode and html, *all* kinds of markup/editors with HTML.

perhaps the issue really is that we start with bbcode with no user choice/abstraction in alternative markup?

I wholeheartedly agree the changeover should be seamless.

[Rimi]

We are not saying the current implementation is how it's going to be. :smile: The future for us, our products, most of our users and some of our competitors is HTML functionality. If you have examples of HTML and bbcode coexisting in a unified editor, I'd welcome you to share for reference. The fact is, the lions share of the issues past and present are due to striking a balance. Again, I welcome examples of those who have achieved the perfect editor using both technologies - we never stop learning. :smile:

There are options and nothing is completely off the table for 4.0, so keep a positive discussion flowing.

Does this count?

http://xenforo.com/community/resources/custom-bb-code-manager.173/