Jump to content

Editor?


ZakRhyno

Recommended Posts

Posted

In the latest blog Matt talks about the editor being updated and stuff about BBCode. There seems to be an issue with what he wishes to put out and what people want. The problem is, I don't get what the post was really talking about and what the issue is. A more clear idea of what is being said should be stated on the blog to people have no earthly idea what is going on. Remember IPS, when posting stuff to blogs you have to bring it down to non tech talk or explain what your talking about. So to my question in the blog it show the updated version. I went to the editors page and see there are tons of options like in the image below.

Capture.JPG

Why are not more of the features in the display of the blog and bring cover over to IPS? The current interface is lacking features that make the current version a shame. Will this be coming to the next release of IPB?

  • Replies 65
  • Created
  • Last Reply
  • Management
Posted

I'm not sure that throwing the kitchen sink into our editor is a good idea.

While I'm sure that many people would like to see more buttons than mission control at NASA, many more would be intimidated by this. Certainly, looking at that screenshot you posted, the sheer number of buttons is very daunting.

Beside that, there are technical reasons we can't have all the buttons at the moment. We don't have BBCode for tables, etc and I'm not sure it's a worthwhile investment of time adding them at this time.

3.4 is really a step towards our goal of removing BBCode as we know it. I think the time has come to retire that now that we have the technology to mark up content correctly thus no longer exposing the end user to the syntax.

Posted

3.4 is really a step towards our goal of removing BBCode as we know it. I think the time has come to retire that now that we have the technology to mark up content correctly thus no longer exposing the end user to the syntax.



Being able to edit the code is an advantage, not a disadvantage.
Posted

I'm not sure that throwing the kitchen sink into our editor is a good idea.



While I'm sure that many people would like to see more buttons than mission control at NASA, many more would be intimidated by this. Certainly, looking at that screenshot you posted, the sheer number of buttons is very daunting.



Beside that, there are technical reasons we can't have all the buttons at the moment. We don't have BBCode for tables, etc and I'm not sure it's a worthwhile investment of time adding them at this time.



3.4 is really a step towards our goal of removing BBCode as we know it. I think the time has come to retire that now that we have the technology to mark up content correctly thus no longer exposing the end user to the syntax.




I see thanks Matt.
  • Management
Posted

Being able to edit the code is an advantage, not a disadvantage.




I quite agree. However, I'd say it's probably easier to edit the HTML than learn a new sub-syntax.

bold versus <b>bold</b> versus <img src="url">




You may as well just display the HTML for those with the desire and ability to edit it.

Posted

I quite agree. However, I'd say it's probably easier to edit the HTML than learn a new sub-syntax.




bold versus <b>bold</b>

[img=url] versus <img src="url">



You may as well just display the HTML for those with the desire and ability to edit it.


>.< the bbcodes, and the ability to read and use them in std mode, is for those that cannot use HTML posting but loath attempting to edit, for example, a 5-page article with heavy formatting applied.
Please do not tell me this new editor is tantamount to open HTML posting.... this was abstracted for a reason, no?
Posted

+1 to Marcher above

I am not liking the way this new editor is being described. It seems you are dumbing the editor way down, so far down it is even below the average users standards. I dread to see how complex posts will turn out with this new editor.

Keep BBCode in or your just confusing things even more for the average user.

Posted

>.< the bbcodes, and the ability to read and use them in std mode, is for those that cannot use HTML posting but loath attempting to edit, for example, a 5-page article with heavy formatting applied.


Please do not tell me this new editor is tantamount to open HTML posting.... this was abstracted for a reason, no?




I believe it was explained in the Editor blog here: http://community.inv...r-improvements/

Happily, the underpinnings to our editor have now been completely rewritten to increase stability and to remove these inconsistencies. Now, the post is actually saved as cleaned HTML (via the excellent HTMLPurify) which means it does not have to be converted between states. You can still edit the BBCode manually if you wish, but this is handled by a single BBCode plug-in for CKEditor. This is very exciting because it frees up IP.Board from having to deal with BBCode manually saving hundreds of lines of code.





From a programmatic point of view this is much easier, no more preDbParse, preDisplayParse, and the gremlins that come with converting HTML to BBCode and back to HTML.

From a user standpoint this is much better as you can expect much more consistent results upon switching from RTE to STD mode and back. The new editor should be a much better experience all around.

:smile:
Posted

Frankly, I think everyone should keep an open mind until they really know what will happen.

For instance, I find it a bit silly to think that an average grandma visiting my site will understand

bold

any easier than

<b>bold</b>



The reality is, she's never going to type out the code anyways. She's going to write some text, highlight it, and click the bold button (or she's going to click the bold button, type her text, and click it again to turn it off).


Really, before judging something you haven't seen, let's be a little patient so you can see the "bigger picture" first.

Posted

Frankly, I think everyone should keep an open mind until they really know what will happen.



For instance, I find it a bit silly to think that an average grandma visiting my site will understand



bold

any easier than

<b>bold</b>



The reality is, she's never going to type out the code anyways. She's going to write some text, highlight it, and click the bold button (or she's going to click the bold button, type her text, and click it again to turn it off).


Really, before judging something you haven't seen, let's be a little patient so you can see the "bigger picture" first.



Would you agree that this change suits the new more than the old? What I mean is someone new joining the forum scene will have no problem adapting but someone who is used to BBCode will be left quite confused for a while.
Posted

Would you agree that this change suits the new more than the old? What I mean is someone new joining the forum scene will have no problem adapting but someone who is used to BBCode will be left quite confused for a while.




Yes, I would. Really, you don't find bbcode all that often anymore. Pretty much the only places still using bbcode are forums, and even then most have an RTE as their default option (which the average user would use). It's mainly the "old timers" that understand bbcode and long to maintain its presence.

Ultimately, however, it's hard to predict the future. I think that it is worthwhile to wait until you get a chance to see and test 3.4 to make a decision on the direction it is going. At that point you can make an educated decision on whether the changes will suit your community better or not. :)
Posted

Frankly, I think everyone should keep an open mind until they really know what will happen.



For instance, I find it a bit silly to think that an average grandma visiting my site will understand



bold

any easier than

<b>bold</b>



The reality is, she's never going to type out the code anyways. She's going to write some text, highlight it, and click the bold button (or she's going to click the bold button, type her text, and click it again to turn it off).


Really, before judging something you haven't seen, let's be a little patient so you can see the "bigger picture" first.


The format of said code I suppose is moot, as long as the granular control of usage admins now enjoy over standard bbcode as we know it remains(who can use what where and all), I, like others, am simply wanting the buttons to not have to code my post directly when in std, while having the visibility of the source(I don't REALLY need to code my posts.... I do that enough in work :smile: ).
if you can insert an attachment tag into the cke.... how hard really is it to satisfy this one base need of old removed, and still sorely needed?
Posted

Frankly, I think everyone should keep an open mind until they really know what will happen.



For instance, I find it a bit silly to think that an average grandma visiting my site will understand



bold

any easier than

<b>bold</b>



The reality is, she's never going to type out the code anyways. She's going to write some text, highlight it, and click the bold button (or she's going to click the bold button, type her text, and click it again to turn it off).


Really, before judging something you haven't seen, let's be a little patient so you can see the "bigger picture" first.

Your example is nice but I think URL is a lot nicer than <img src="URL" />. The problem becomes when you see something like this.

http://imgur.com/iQosQ?tags

Says very clearly which code to use on message boards and forums and lots of image hosting sites do this.

But hey I can see the benefits of this. Let me know if I'm going too far but these changes mean that people could potentially put height and width properties in image tags, right? Even live resizing of images in ckeditor could be a possibility now? I guess I'm not fully understanding what these changes actually mean...I might be building up expectations that are just too high and not what you're planning at all here. Admittedly I don't want to see bbcode go, but maybe that's because I've been on forums for almost 10 years (then again I started on lithium forums which do use HTML and not bbcode..oooh IPS competing with lithium now.. :3). However, having a source mode where you can edit html..? That's pretty awesome IMO if all the security is in place..and frankly if such a thing were possible then I totally don't care if you're still not implementing the buttons in standard mode. Just...that's a big change.

And omg we could do tables too.... D:

Did I go too far? <_<
Posted

http://imgur.com/iQosQ?tags

Says very clearly which code to use on message boards and forums and lots of image hosting sites do this.





And this code would still be able to be used, the only change in 3.4 is mainly that BBCode no longer "exists" outside of the editor. You can still post %7Boption%7D tags and they'll be parsed.
Posted

And this code would still be able to be used, the only change in 3.4 is mainly that BBCode no longer "exists" outside of the editor. You can still post %7Boption%7D tags and they'll be parsed.


Awesome so basically I misinterpreted everything. That's good. Does this mean that adding height and width properties to image tags is still a no?

You know what? I think it's better to just play with it. So hurry up with the beta release. :3
Posted

I just want to be able to post tables from Word documents that will display and edit properly and save properly. At the moment its a lot of trouble to do. Tables should be pretty easy for the RTE to handle I would have thought, bt I'm no programmer.

Posted

I just want to be able to post tables from Word documents that will display and edit properly and save properly. At the moment its a lot of trouble to do. Tables should be pretty easy for the RTE to handle I would have thought, bt I'm no programmer.




The RTE can handle them no problem. The "problem" is that IP.Board (and most forum packages really) is current bbcode-based on the backend, so anything submitted into the RTE has to be turned into bbcode (or a suitable bbcode adaptation has to be available), and that's where it starts getting tricky. As we move to all-HTML, this won't be an issue.
Posted

The RTE can handle them no problem. The "problem" is that IP.Board (and most forum packages really) is current bbcode-based on the backend, so anything submitted into the RTE has to be turned into bbcode (or a suitable bbcode adaptation has to be available), and that's where it starts getting tricky. As we move to all-HTML, this won't be an issue.




Ah I understand now. Thanks.
  • 2 weeks later...
Posted

scenario


I am allowed to post HTML


I am not allowed to use the bold bbcode


<b> will it stop me???</b>


I ask for information on control, if 'bbcode' is gone, will we still have control over our posted content?


post-201612-0-66783600-1344444872_thumb.

Would really like an answer to this, is this now free-mill run amok or has nothing changed here?
How does it handle the differentiation between acceptable 'bbcodes'(call it what you will, sure is stored as HTML, w/e) and RAW posted HTML not in the 'bbcodes' allowed?
I will be... oh so upset if the ability to block guests from posting anchors vanishes, or find out having HTML posting permissions still means x html tags are unusable through said configuration.

Archived

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

  • Recently Browsing   0 members

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