New Editor: Redactor (Part 1)

  • Burning Board 4.1 will introduce the new editor Redactor, a lightweight and jQuery based WYSIWYG editor. It is superior to the currently used CKEditor in many different ways, it is a lot smaller and loads in fractions of the time required to load CKEditor. Completely built upon jQuery, it provides a better and more stable support for different browsers and mobile devices. Furthermore it offers an awesome Plugin interface, granting us full control over the editor both in terms of resolving issues or extending it with custom functionality.


    Visual appearance



    We have spend a lot of time tweaking the editor and working on its visual appearance, it inherits all style properties and automatically adapts to the used style. The message tab menu below has been redesigned to integrate visually into the editor, providing a more streamlined design. The CKEditor in Burning Board 4.0 always looked like a foreign object and did not integrate itself into the overall appearance at all.


    Enhanced Quick Reply



    Over the time many users adapted to the quick reply features introduced in Burning Board 4.0, but it provided just a simple message input and simple tasks (e.g. adding attachments) required one to go for the extra-mile, namely the extended quick reply. The message tab menu has been added and will aid you to write messages without the need of accessing a different page. One of our primary goals during the redesign of the message tab menu was the ability for users to instantly recognize the interface they're already used to. Depending on the context there may be a different set of features presented. By the way, you can still access the extended quick reply if you like to, that's entirely up to you.


    The tab menu is collapsed by default to prevent visual clutter, clicking on one of the tabs will show its contents. The shown tabs (if they're shown at all) depend on the context, while the first tab is automatically open on the extended message form, a different tab will be initially shown when inline editing.



    The smilies are available in an own tab and are available in every context. Burning Board 4.0 was rather limited when it came to smilies, the system present you only the general ones, completely leaving a user unaware of the other categories. With Burning Board 4.1 all categories are available and their contents will be loaded once needed.



    As I said earlier, not being able to manage attachments in place is a rather bad thing. The quick reply (and the inline editing) are pretty straightforward: You can write your message instantly and still be able to scroll up to take a glimpse at the previous messages, preserving the context and ideally your thoughts. We're closing this gap with Burning Board 4.1, attachments will be available directly, without the need of changing to a different page.



    Last but not least the tab settings is intended to provide useful options depending on the context, for example it will show different options in the inline editing process. In addition plugins are able to add new tabs and extend this tab to allow for better integration with existing systems.


    Attachments


    Images uploaded as attachment are now displayed using their preview image, while non-images will continue to show the raw BBCode since there is nothing else to display. We're hoping that this addition will help you to write messages while referencing to your attached images, generating a better WYSIWYG experience:



    Inline Editing



    The inline editor provides you with the same interface you're already used to when creating or replying to threads. Again you have the same features available as during the quick reply, including the attachment management. The screenshot above illustrates the context-sensitive message tab menu I've mentioned earlier: It offers you to append/remove the edit notice (if you have the permissions to do so) and asks for an editing reason. It is worth noting that I did not open the tab, it expands itself once you're inline editing, trying to provide you with the most useful action.


    Compatibility


    Redactor will be available on all recent versions of desktop browsers and mobile devices. We'll be focusing on keeping the support up for different mobile devices, the aforementioned plugin interface provides us with the ability to selectively apply modifications to ensure everything is running smooth on your smartphone or tablet.



    That's it for now, the next spotlight will dive deeper into our Redactor integration, including drag & drop uploads, quote management and message autosave.

  • Semi-off-topic-ish, but I couldn't help but notice the "Delayed publishing" checkbox in that first pic. Is that feature new for threads and will there be a per-usergroup option to enable/disable it?

  • Semi-off-topic-ish, but I couldn't help but notice the "Delayed publishing" checkbox in that first pic. Is that feature new for threads and will there be a per-usergroup option to enable/disable it?


    Only users with the ability to disable/approve threads are given this option. And yes, it's new :)

  • One of my members bring up a few good questions



    "what font choices will be available to us?"



    "Will the 'save draft' option still be available as a manual selection or is everything to be automatically saved? (I like the save draft manual function 'cause sometimes I don't have time for the autosave to kick in on its own. I have lost lines at times because of the lag sometimes in the auto autosave vs. the manual activation of the save draft feature). "

  • "what font choices will be available to us?"


    The same set of fonts available in the ACP and in CKEditor (Burning Board 4.0).


    "Will the 'save draft' option still be available as a manual selection or is everything to be automatically saved? (I like the save draft manual function 'cause sometimes I don't have time for the autosave to kick in on its own. I have lost lines at times because of the lag sometimes in the auto autosave vs. the manual activation of the save draft feature). "


    Messages will be saved every two minutes using the browser's localStorage (prevents "hammering" the server).


  • The same set of fonts available in the ACP and in CKEditor (Burning Board 4.0).


    Thanks for that information :)



    Messages will be saved every two minutes using the browser's localStorage (prevents "hammering" the server).


    In the current development that I use, it already automatically saves after X time (believe its 2 minutes as well). But in addition, they also have a "save draft button" that can be used to force the system to save a draft at that moment.


    This can be VERY useful if you're in the middle of typing a lengthy reply and suddenly cannot complete it, allowing you to pick up later. It's also useful on some mobile devices that may not refresh correctly for the auto save.


    So will this include a save button in the editor? (hopes, the answer is, yes).

  • There is no button to force a save at the user's command, it works in the background. In addition, since it stores it right in the browser, the autosave will keep working even if your device can no longer establish a connection to the server, e.g. if you're on your mobile and suddenly your connection is gone.


    It's also useful on some mobile devices that may not refresh correctly for the auto save.


    I'm curious, what exactly is this about?

  • I'm curious, what exactly is this about?


    I was informed that there are some mobile devices that do not always automatically refresh. I've never experienced this myself, so I wouldn't know where to start on that.


    There is no button to force a save at the user's command, it works in the background.


    Would really be nice if there was a save function button.


    In addition, since it stores it right in the browser


    Would be nice (better) if it loaded it into the database in a temp location that would automatically clear after a specified expired time

  • I was informed that there are some mobile devices that do not always automatically refresh. I've never experienced this myself, so I wouldn't know where to start on that.


    I'm sorry, I should have been more specific. What is meant by the term "automatic refresh"?

  • Messages will be saved every two minutes using the browser's localStorage (prevents "hammering" the server).


    In order to achieve this the browser would need to refresh and / or execute a timed javascript or jquery script every 2 minutes


    I'm sorry, I should have been more specific. What is meant by the term "automatic refresh"?


    Not all mobile devices / browsers can do this. In fact some mobile providers as a security measure prevent such automatic "refreshes" (or time execute).


    I use the word refresh in this case generically (lets not get hung up on the term).

  • hat's the first time, that i hear this. A mobile provider can't prevent that.


    You'd be surprised on what providers feel they "can" do in their roms (at least in America). What the manufacturer released vs what the provider customizes and authorizes for their customers are very different... I've seen software patches that completely disabled hardware, by design. A browser is very simple by comparison

  • Can you give more information about that? Which providers are that and where can we find any information about it?


    But as WBB 4.1 will use localStorage, this is not an issue. Things get saved in the browser itself, making timed requests unnecessary.



    But I agree, a way to force the save would be great. If you are writing a post and something comes up, you'll sometimes want to save it right away and close the browser instead of waiting up to 2 minutes.

    "A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP" — Leonard Nimoy

  • Can you give more information about that? Which providers are that and where can we find any information about it?


    I personally have never had this issue. However, I know others who have had this issue. On another development the work around was not to depend on the browser.


    1) There was a save function added so you could manually save a draft


    2) The save was saved in the database temporarily as not to depend on the browser


    I think #2 is important because if my browser was to crash (as it has sometimes), I know that my lengthy post is not lost. This plays heavily when blogging (blogs)


    But as WBB 4.1 will use localStorage, this is not an issue. Things get saved in the browser itself, making timed requests unnecessary.


    See above why its better not to depend on the browser.



    CBut I agree, a way to force the save would be great. If you are writing a post and something comes up, you'll sometimes want to save it right away and close the browser instead of waiting up to 2 minutes.


    So long as your browser keeps everything and doesn't clear it's cache files. It's better to have this in the database temporarily

  • Localstorage has nothing to do with the browser cache.


    Was it not you who linked to this?
    http://caniuse.com/#search=localstorage


    In fact you do so in this post here
    WBB4.1 — New Editor: Redactor (Part 1)


    Cookies ... cache... Lets not get hung up on terminology. Both are dependent on your browser.


    Fireing updates to the sql server every 2 minutes is not, what i would call "better"


    Depending on your browser isn't what I'd call "better". The whole point of the save function is so you don't lose something if you cannot finish it right away or if something were to go wrong.

  • Using the localstorage is more secure than using the DB. What, if the DB has a temporary problem and if its unable so save your post? Then, it gets lost. That wont happen, when using localstorage ;)


    Cookies ... cache... Lets not get hung up on terminology. Both are dependent on your browser.


    And both have nothing to do with localstorage. Localstorage is completely independend and you have to clear it manually, because most browsers dont offer an option to clear it (except for the developer consoles).

  • Using the localstorage is more secure than using the DB. What, if the DB has a temporary problem and if its unable so save your post? Then, it gets lost. That wont happen, when using localstorage


    Why not both? I personally like the ability to start my post on my tablet and if the battery dies while I'm on the go, I can pick up where I left on my desktop.


    And both have nothing to do with localstorage. Localstorage is completely independend and you have to clear it manually, because most browsers dont offer an option to clear it (except for the developer consoles).


    You'd be surprised on how many people clear it regularly or have security programs that clear it as soon as you close your browser.


    ccleaner (for example) is a popular app people use on their desktop that does this by default.