Jump to content

Editor Feedback


Lindy

Recommended Posts

Posted

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.

Lindy, the perfect editor is the one you want to use for your community. Maybe stop trying to please everyone and approach the editor in a different way. That's why I posted the links I did.

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

You can see clearly that there are plenty of different editors you can use for Joomla, for example. Plus then you only have to provide a default editor and let the community do as it pleases with other options.

Here is some feedback from one of my users:

Ultimately I don’t see the need for a WYSIWYG editor in the first place—in fact they are contradictory in terms. Bugs where you type just after a quote and then your text gets added to the quote itself is common to all WYSIWYG editors. The whole purpose of WYSIWYG is to give the user a clear understanding of what the end result will be, which is a purpose completely defeated by WYSIWYG editors because:

  • It is no longer clear what any of the actions we taking during the editing process will be. When I paste into a code block, will it break the code block? Will my text just under a quote end up actually getting added to the quote itself? Will pressing Tab actually add a tab, or will it go to another control? Will whitespace be removed when I paste it into the editor? Will it be removed when I switch from raw to standard?
  • The only time when we need to check how the post will actually appear in its final form is just before we actually post it. If we have doubts about that then there is always the preview button.


In conclusion, some of the bugs I posted here probably can’t be fixed anyway (I have yet to see any WYSIWYG editor without a few of these issues) but even if they could I don’t think it would be worth the time. The inherent flaw with all WYSIWYG editors is that they never know where to place the text you are typing. If your cursor immediately follows a bold word and you type a character, should it be inside the b tag or outside of it? There is no universal answer.

Instead, not only will no number of improvements to the WYSIWYG system make it useful, it only slows us all down as we try to post. I used to go to raw mode only to avoid having my pasted code lose its opening per-line whitespace, but now I have to jump back to raw mode constantly to fix little things, and now I even have to add all code tags manually.

The previous system was perfectly fine (except that pasting text in standard mode removed whitespace). Having the tags visible in standard mode was a good thing. It made 10 fewer reasons to jump back to raw mode, and also made the editor itself more stable. If I ever did question how my post would look I would use the preview button. 99% of the time, however, I had no questions about how my post would appear (if I was wrong I would just edit it), which make a WYSIWYG editor 99% useless.

  • Replies 170
  • Created
  • Last Reply
Posted

Why doesn't IPS realize that pretty much all complaints with the editor would be resolved if they added buttons to the standard editor?

Posted

Why doesn't IPS realize that pretty much all complaints with the editor would be resolved if they added buttons to the standard editor?

That's really wishful thinking.

  • Management
Posted

I will convey my point one last time and then I am bowing out of this discussion from a technical standpoint - I am admittedly not a programmer and am basing my statements solely on what's been conveyed to me by our development team. The purpose of this discussion is for you to provide your feedback and then myself and the management team will meet with development to determine the next step. We are committed to satisfying as many concerns as possible, but we need to be realistic. Our immediate goal is to fix up the code and quote issues. Other tasks may or may not have to wait for 4.0.

With that, I will reiterate again -- a few of you posting here really do represent a minority. Do not believe for a moment that the bulk of our userbase is going to comment on "parsing text in standard mode removed whitespace." :smile: That does NOT mean the minority is to be ignored or devalued and that is NOT what I am saying, even in the least. I am saying that we have to consider the big picture. We have to consider that less than 10% of our customer base visit these forums and those that do tend to be on the slightly more advanced side. We have to consider that our customer base consists more than just techies and instead range from elderly that type 'www.invisionpower.com' into Google and click the result to those who want to mix BBCode inside an RTE. :smile:

It's easy to have a solution when it's targeted at your individual needs.

Mat: I like your idea of a default editor and multiple alternate editors to suit specific needs. Again, I'm not a developer and am unaware of the feasibility from OUR platform's standpoint, but I can tell you it sounds like a logistical difficulty. Supporting and maintaining multiple editors doesn't sound like a worthwhile venture, but perhaps we can find a happy medium that allows more extensibility.

Why doesn't IPS realize that pretty much all complaints with the editor would be resolved if they added buttons to the standard editor?

That's all it would take? :)

Posted


That's really wishful thinking.

No. It's a question.

That's all it would take? :smile:

Yes. That is all it would take. By doing that you reintroduce the default editor system we had in 3.1.4 and every version before that. Back when the editor was not a source of complaint. You give us back a form of editing that makes syntax input (whether it be bbcode or html) easy to use and friendly. It's what has always been preferred and what has been asked for for nearly 2 years. You can only benefit by bringing it back.
Posted

Every update of IPB = editor was problem (3.1.4 to 3.2.0, 3.2.0 to 3.2.x, 3.2.x to 3.3.x and last 3.3.x to 3.4.x - nearly 2 years). For me that says that development team can not execute their work - change team and let them to experiment next few years ... or send them to extra education, but try to sell finished and working product.

Editor is most immportant part of every community /where people still write posts and make threads).

regards

bosss

Posted

if I asked any of my members what bbcode was they wouldn't have a clue and most user are the same. the use the editor to make any changes to the text they want. i would say though that heh change needs to be made to just html then it needs to be done quickly and not be drawn out.

Posted

It's easy to have a solution when it's targeted at your individual needs.

Mat: I like your idea of a default editor and multiple alternate editors to suit specific needs. Again, I'm not a developer and am unaware of the feasibility from OUR platform's standpoint, but I can tell you it sounds like a logistical difficulty. Supporting and maintaining multiple editors doesn't sound like a worthwhile venture, but perhaps we can find a happy medium that allows more extensibility.

It was definitely easier prior the latest update I think but is still very doable. I think there is a lot of "special case" code now that ties text processing to how ckeditor works that needs to be gutted. A lot is related to bbcode in fact. BUT, I think for guys like Marcher and me this adds flexibility even for particular applications to use an editor more suited for the task.

With the templating and hooks system that you guys developed, a pluggable editor should be pretty simple with a little thought. It would obviously have to respond to some javascript callbacks for things like button presses and such.. but it should be very doable. For you guys though I wouldn't support editors beyond the default editor unless you develop an alternative yourself.

Also, allowing basic formatting buttons in the standard editor would be helpful. That.. and a way to turn off the WYSIWYG editor by default (is there one?).

Posted

That.. and a way to turn off the WYSIWYG editor by default (is there one?).

When you click the switch it saves the option. So whenever you post again the standard editor would still be the option you had set last.

Posted

I don't think there is anything wrong with phasing out bbcode by default, but something should be present in order to make complicated custom things easier to write for end users (like custom HTML tags or whatnot). In my mind, the best editor needs to fulfill the following roles (all equally important in my mind):

1. Cater to normal users who have not a clue of what bbcode or HTML are.

2. Cater to power users who have a firm grasp of bbcode/HTML and might even prefer typing it out plain rather than using a WYISWYG environment.

3. Cater to communities who have different goals and different levels of technical competence.

The easiest way I can think of to accomplish all three points is the following (high level solutions, not getting into technical points yet):

1. A WYSIWYG editor to cater to normal users. You already have one of these, and keeping it around is very important.

2. A method of turning OFF said WYSIWYG editor for power users so they may type the way they wish to. I forgot which forum system it was, but it offered a choice in the user cp between WYSIWYG editor, an editor with buttons to insert markup, and a plain text box. Adding such an option (and making the software remember what is chosen for default display to that user) would be an excellent way to cater to power users.

3. Allow for the ability to install mods that extend the functionality of the editor and/or replace parts of it entirely, so that communities with widely disparate goals on what they need in an editor can get those goals satisfied without compromising the editor's simplicity/functionality for anyone else. Additionally, allow admins in the admin cp to define custom markup (bb code currently, html/xml tags in the future possibly) to make it easier to format certain commonly-used things in that community. Offer as much flexibility to the community admins as you can so that they may customize their editor to their specific community's needs.

Once I think about it a bit more, I'll be able to offer a graphic hopefully explaining from a technical standpoint how all of that can come together.

Posted

It was definitely easier prior the latest update I think but is still very doable. I think there is a lot of "special case" code now that ties text processing to how ckeditor works that needs to be gutted. A lot is related to bbcode in fact. BUT, I think for guys like Marcher and me this adds flexibility even for particular applications to use an editor more suited for the task.

With the templating and hooks system that you guys developed, a pluggable editor should be pretty simple with a little thought. It would obviously have to respond to some javascript callbacks for things like button presses and such.. but it should be very doable. For you guys though I wouldn't support editors beyond the default editor unless you develop an alternative yourself.

Also, allowing basic formatting buttons in the standard editor would be helpful. That.. and a way to turn off the WYSIWYG editor by default (is there one?).

-_.- Been wanting to fix IPBHTML logic in the native code tag for like... *ever*.

Posted

I don't see anything wrong with phasing out BBCode either, as long as the new way allows for enough flexibility.

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.

Man, this would be awesome to have. I'd love to be able to switch my users to use markdown instead of bbcode / html.

In any case, a biggie for my users is not being able to use bbcode buttons when the source mode is off. Yes, I run a specialized forum (similar to StackOverflow) and yes I might be a smaller percentage of the market... but topic after topic I see this request, so I know I'm not alone here. I'd be a lot happier with that updated & a fix for the quoting/code parts as already mentioned by Lindy.
Posted

I'm a member of a very large vbulletin forum which recently switched to xenforo, a forum software that doesn't have bbcode.

Xenforo does not have bbcode?

Posted

Thanks for asking user feedback, of course every user needs are different, but here is my opinion based on my (large) communities

1) By default, turn off the RTE. The default editor for QUICK REPLIES should be something with few buttons (a-la-facebook) probably just bold, italic, and a few more. Users should be able to turn RTE on by default with admin CP ( and not within the editor )

2) There should be a way, inside the quick reply, to UPLOAD A FILE (especially an image) without going RTE. Especially as you do REMOVE the image upload built in CKE. Please leave it there, or better, replace it with something uploading in a special user galleries ccalled "uploads".

3) I am not fond of the idea to get rid of BBcode internally; but if it makes the baord display pages faster, I can cope with it.

4) everything has been said about quotes. If I may just add, I'd like quote to be limited in size via an ACP setting ( eg no more than X words quoted, and no image quoted settings )

thanks for reading, if you did read :)

Posted

Just a quick suggestion on a way to improve the convertibility of bbcode to HTML and back:

Add a class attribute to the HTML that a bbcode translates to. Specify it as "bbcode<insertname>tag" and then alter the parser so that it looks for tags with this attribute and parses them.

Similarly you could wrap the HTML tags that originate from bbcode in HTML comments. Hell you could even make the comment identifiers unique which would aid parsing things like multi-level quotes. Then you would have the bbcode parser search for these specific comments and certain tags following them before converting the HTML into bbcode and vice versa.

Posted

As someone that has forum of mainly photo and video sharing we tend to use BBCodes as a normal practice for showing images using forum thumbnail codes and a download button for file links.

As we have a tutorial on how new users are to post topics they find it very easy to use.

For us the real thing lacking is the ability to use table layouts as in Vbulletin. We moved to IPB because of some of the better features it has, but not having tables as a standard option is leading us to consider going back to VB. I have tried some of the mods to use tables in posts but they are far from easy to use for a normal user.

While I understand that not all forum owners want to have every option available for the editor for reason they have already explained. I can not see why we can not have an editor that the forum owner can choose which options are allowed to be used, of course unless this is very hard to do but looking at joomla and other site software this is an option or at least a mod that can be applied.

Surely allowing us as owners and admins to be able to choose which option's we give our users in the editor is the best way to go that is my humble opinion anyway.

Posted

Editor is one of the most critical feature on any forum solution as content is the main difference creator between a forum and a social network website.


Any improvement to editor is always welcomed by me however there are couple very critical things that should be considered when you are implementing improvement to Editor.

  1. Backward compatibility should always exist without backward compatibility nothing should be implemented at all and it can't be recalled as an improvement
  2. Users should not face key changes as all users will have issues if posting style is completely changed
  3. Forum users differ from SN users. Many new user who start posting messages on our boards already know BBcode usage as they have been member to other communities. So i kind of disagree with Lindy regarding Power users needs are different then 95% of their users.
  4. Editor should have a standard usage on all IPB functionality. It should be same within Content or Forum pages
Posted

Editor is one of the most critical feature on any forum solution as content is the main difference creator between a forum and a social network website.


Any improvement to editor is always welcomed by me however there are couple very critical things that should be considered when you are implementing improvement to Editor.

  1. Backward compatibility should always exist without backward compatibility nothing should be implemented at all and it can't be recalled as an improvement
  2. Users should not face key changes as all users will have issues if posting style is completely changed
  3. Forum users differ from SN users. Many new user who start posting messages on our boards already know BBcode usage as they have been member to other communities. So i kind of disagree with Lindy regarding Power users needs are different then 95% of their users.
  4. Editor should have a standard usage on all IPB functionality. It should be same within Content or Forum pages

I agree with above except point 3. While forum users may differ from SN users that does not mean that they know BB code. I can guarantee that virtually none of my 11,000 members know what BB code is.

All they want is a simple WYSIWG editor allowing them to do simple text formats, post images and links and quote previous posts. The editor must be simple and intuitive for these users.

Posted

The attached image is what happens when members go to post a spoiler that is made up of a lot of text. They have to hit the backspace loosing all the post they've started

This is after they figure out the BB spoiler tags is in the light switch box

It is frustrating to say the least

post-278785-0-56699800-1357106880_thumb.

Posted

What I do find *really* annoying about the editor on 3.4.2 is that I no longer get a 'paste' option in WYSIWYG. Therefore to paste, for example, a link into this reply I first need to click the editor toggle button (or whatever its called, top left on the editor).

How on earth are my forum members supposed to know that? Surely paste function should be a basic WYSIWYG function? (currently use 3.3.1 which does have paste). I therefore can't update to 3.4.* until this is fixed. Not sure if its a bug or a 'development' of the editor.

Posted

With that, I will reiterate again -- a few of you posting here really do represent a minority.

What about the members who have not yet posted? I've just been silently reading/watching/waiting for IPS to give us our options back. My editor is completely NOT what I want at the moment and it has proved to be a big pain in the "you know what" since I've upgraded because now I cannot make the changes I want. And because of the recent changes IPS has made, I am very reluctant and probably WILL NOT EVER upgrade again until I've waited a month for more of these 'feedback' topics to pop up for reference.

My IPB software will not be upgraded again for a while since I see very little that needs attention, getting fixed. Rather IPS makes changes that many of us aren't concerned about.

  • Management
Posted

Rather IPS makes changes that many of us aren't concerned about.

I agree with you in this particular instance and offer my deepest apologies. We are taking steps to minimize this in the future.

Please let us know what you're looking for in the editor. :smile:

Posted

Phasing out BBCode and going for all-HTML down the road is a good thing, it just needs to work correctly.

People get all sorts of annoyed when they go to edit a post and some new behind the scenes change which they don't care about totally messes it up and causes a load of work for them. Also in general, most users hate changes and it discourages them from posting because they don't want to bother getting to grips with something new.

The most important thing though, and it's been said by everyone here, is it needs to have total backwards compatibility. Parsing some BBCode into HTML but they might not turn out exactly how the BBCode displayed things? Then don't parse them and save it that way, you need to save the original so that the content as it was intended to be displayed isn't lost because of some screw up made in conversion.

I always love to upgrade our forums and get the latest features, but the biggest worry for me is always that some change that has been made (just like this) might cause our users to dislike the forum and thus posting will go downhill. It's also not IPS that takes the blame when this happens, our users hold us responsible and we suffer for it as well.

Posted

80-20 rule, the power users are why bbcode needs to remain supported. Do 20% of your users create 80% of your content? I think power users on most forums are responsible for much more than 80%. For example 10% of IPS customers post in these forums. Of that 10%, a much smaller number are regular contributors. They tend to be more technical, the power users. 95% of users may only want a WYSIWYG editor, but the other 5% are very important.

Power users like bbcode. They've probably been using forum software a long time, and across multiple platforms. They likely have some saved bbcode text they reuse. They can produce complex posts and have them look great. bbcode is the language of forums. Why would we want to distance our power users?

WYSIWYG is terrific for the other 80%. They have high numbers, but don't produce the great content that is probably driving traffic to forums. The RTF editor never did work well before CKEditor. Now it's easier for them to format their posts. We could argue whether we want posts full of purple, italic, comic sans, but that's for another discussion.

What changes should be made to the editor? I like the plugin model. Give the bbcode fans a functioning editor with working buttons. Give the newbies the pretty, pure WYSIWYG CKEditor editor. It sounds like there's strong support for Markdown. I'd like to give my readers the option. Make it a per user option, and let them decide. Quit trying to be everything to everyone with a single editor. Also as mentioned above, backward compatibility is a must.

I'm sure IPS didn't start this discussion to develop and support yet another editor (Markdown). However, with a plugin system maybe IPS doesn't even have to write or maintain any of these editors, just lay the framework to support the plugins. Just please don't force everyone into an HTML WYSIWYG editor with dwindling support for bbcode.

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...