New Features in Burning Board 4.1: New Editor (Part 1)

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.

Comments 34

Alright I will keep that in mind if you ask for something again. Usually the user would like to ready first something before just getting the zip file. Not everyone might be adding links to trustworthy sites :) so just for security reasons :) but we are getting off topic here.
Check out the delayed post plugin. It's not save as drsft but you can miss use it for it.

And yes many refer to his site since everyone know he is producing great products.


I think my frustration comes from people referring to an empty void... That is to say, when someone post a link to something, I and others expect a direct link to X and not just the thread that talks about it, but exactly where it can be obtained.

That is the package server of @TimWolla one of the developers of woltlab. There you can browse for plugins he put online. It is currently "only" release candidate 2.
And yes many refer to his site since everyone know he is producing great products.

When visiting https://tims.bastelstu.be/index.php/Products/, i can download everything. Even as guest.

However, the mentioned plugin isnt listed there. But you can get it here: https://packages.bastelstu.be/de.bisaboard.w…osts/2.0.0_rc_1

I knew you could get addons here
https://tims.bastelstu.be/index.php/Products/

But in the case of the original post (and often the many referrals), people tend to refer that site and the actual download (as in this case) is else where. Love to know where you found that download link in the first place.

Once I saw the link to that site, I sort of ignored it... I wish people would stop referring me to that site anytime they claim there is an addon for X, Y, Z ... I've never seen an addon there. Unless it's hidden from guest view, all I ever see there is people talking about addons, but no actual files.

When visiting https://tims.bastelstu.be/index.php/Products/, i can download everything. Even as guest.

However, the mentioned plugin isnt listed there. But you can get it here: https://packages.bastelstu.be/de.bisaboard.w…osts/2.0.0_rc_1

BTW: The message will be saved every minute (https://github.com/WoltLab/WCF/bl…s/wutil.js#L197).


This is good news. :) That may improve a few things for my members who type very fast. I have 1 user in particular in mind that seems to be able to write up whole Wikipedia type entries a minute apart. So having it save quicker and often is good.

Adam did you check out my link to the plugin for delayed posting. It's not exactly what you want "save drsft" but this would get you a work around if woltlab decides not to include it in wbb4.1


Once I saw the link to that site, I sort of ignored it... I wish people would stop referring me to that site anytime they claim there is an addon for X, Y, Z ... I've never seen an addon there. Unless it's hidden from guest view, all I ever see there is people talking about addons, but no actual files.

@Netzwerg my argument is to have both.

I have members who make REALLY lengthy replies and not your typical few lines (replies even longer and bigger than you just posted in reply). Especially bloggers which I hope to add Woltlab Blogs.

Some of these members use alternative browsers and security measures. And the mentality of the younger generation is it either works for them or it does not. This is where social media is gaining over forums... The mentality is social media adapts to the user and forums expects the user to adapt to the forum.

Well, let's summarize both sides, shall we?

Saving in the DB on the server:
+ Works in all Browsers
+ You can pick up your work on another device
+ You can't loose your work to dubious "cleaner" programs or stupid manufacturers
- You are screwed when you loose your internet connection (which, on mobile devices, is a real problem)
- If timed requests are made, the server is hammered with requests when many people write posts

Saving in localStorage:
+ Works in all modern browsers (except Opera Mini, which sucks anyway and doesn't see much usage)
+ You can increase the saving interval as much as you like without hammering the server
+ You can write your post & save it without internet connection and post it when you have established a connection again
- You can loose some work upon browser crash (which isn't really a valid argument, since when your browser crashes with the other method you'll also loose up to the last 2 mins of work)
- If you don't know that localStorage and cache are completely different things and have some cleaner tool clean it up, you can loose work. This argument is also kind of moot, since you can also loose work if you manually delete files from the file system or have a cleaner tool clean them up, but saving files on your file system isn't insecure per se. It just misuse of tools that leads to data loss.


So, both method have valid Pros and Cons. Saving in localStorage actually is quite clever, since you do not depend on a working internet connection and can write posts from wherever you want even without internet connection and then post them at a later date. On the other hand, having things saved locally means you can not pick it up on another device and it also means that you can loose the post if you clear the localStorage. But in the same way that you trust the web admin not to delete your stored posts on the server, the same way you should care about not deleting contents from your own device.

An important con against the timed requests is the use of webspaces. Many webspace providers do not allow regular requests and treat them like chats. This might not be an issue when you are on your own server, but WBB especially also target normal webspaces. And you don#t wanna hammer those with requests. That's why i think using a hybrid-approach that uses both localStorage and timed requests to save posts on the server is best left for a plugin.

Adam did you check out my link to the plugin for delayed posting. It's not exactly what you want "save drsft" but this would get you a work around if woltlab decides not to include it in wbb4.1

No. Every browser that supports HTML5 (and thats something, that every (or every "known") smartphone browser does) also supports localstorage (except for Opera Mini, which sucks anyways). See http://mobilehtml5.org/ (Web storage)


We can keep going on in circles about this, but I stand by my original statement... It is NOT a good idea to depend upon the mobile web browser to execute a script every 2 minutes; especially since the cellular providers have an established history of overriding default behaviour system wide -vs- the intended manufacture stock settings (ATT and Verizon are good examples of this).

You're forgetting the mobile device argument

No. Every browser that supports HTML5 (and thats something, that every (or every "known") smartphone browser does) also supports localstorage (except for Opera Mini, which sucks anyways). See http://mobilehtml5.org/ (Web storage)

That's the only valid argument

You're forgetting the mobile device argument. Which is a valid argument. There are other developments that have used Redactor and faced this possible.

I use it by myself and localstorage is NOT included as option, by default. You can just get it via WinApp2.

I forget what apps are common on Windows that do this, but I know there are a lot of them. I usu Ubuntu so while this will not directly affect me, it will my users.

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.

That's the only valid argument ;)

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

I use it by myself and localstorage is NOT included as option, by default. You can just get it via WinApp2.

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.

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).

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.

So long as your browser keeps everything and doesn't clear it's cache files.

Localstorage has nothing to do with the browser cache.

It's better to have this in the database temporarily

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

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

https://tims.bastelstu.be/forum/index.ph…verf%C3%BCgbar/

it is not exactly what you want (save as draft) but you can "delay the posting".

This "right" is combined with the user right to "active/disable" the thread/post.

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.

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

Not all mobile devices / browsers can do this

http://caniuse.com/#search=localstorage

In fact some mobile providers as a security measure prevent such automatic "refreshes" (or time execute).

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

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).

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"?

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

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?


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).

"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).