# Is anyone seriously using the Ajax-preview for forum entries? (Features)

Hello

We discuss the sense or nonsense of the preview feature over there in a Github-issue (#638). Please read the arguments in the issue, I don't want to begin with a repetition here.

The feature makes it necessary to adapt many changes of the handling of entry content, possibly with special cases for only this one feature. Currently it's the handling of the optional JS-library MathJax, which might be necessary for technical or scientific forums only. The library formats mathematical formulas from a LaTeX source in a forum entry. Next time it could be something completely, something, that would affect everyone.

So most of the forum operators will never need the currently affected library. On the other hand, cases like this makes it necessary to handle the view with special treatment (what we call an "Extrawurst" in German), completely independent from the number of affected users. It might be one forum or all forums, that run with MLF.

The result of the discussion so far is, that we (Micha, Alfie and me) doesn't really use this feature. So we want to ask you, if you as forum operators and your audience use this feature in a serious manner (not only once every when and then). If not, we tend to remove it.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

## Is anyone using the Ajax-preview: A request for forgiveness

Hello

Because of an error I made while classifying the entries as spam or ham I deleted the replies in this thread. I am very sorry.

1. Magma:

- uses the preview feature often
- uses it among other things because when writing a reply one does not see the entry one replies to

2. Micha:

- knows about the issue to not seeing the entry, one replies to and proposes to display the entry, one replies to, above the answer field, similar to the kind, it is handled in the SelfHTML-forum

3: Me:

- FACK to Michas proposal

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

## A proposal for making the parent entry visible when replying

Hello

2. Micha:

- knows about the issue to not seeing the entry, one replies to and proposes to display the entry, one replies to, above the answer field, similar to the kind, it is handled in the SelfHTML-forum

And so it came, that I made a mockup of a new posting page. This proposal, if and when implemented, makes one of the arguments for keeping the preview-bubble-feature obsolete.

The page contains …

1. … the parent posting, one want's to reply to, …
2. … the (optional) preview block and …
3. … the posting form (here one for a registered user)

- All elements of the enty form and all links are disabled in the mockup.
- If the planned entry is the starting entry for a new thread, the block for the parent entry (1.) does not apply.
- If one didn't request the preview, the block for the preview (2.) does not apply.

So if one starts a new thread, one sees only the entry form when opening the posting page. If one uses the preview-button, one additionally sees the preview block. Currently the preview gets displayed above the entry form. I didn't change this behaviour in the mockup.

If one wants to write a reply, one sees the parent entry block and the entry form for the reply below. If one uses the preview-button, one additionally sees the preview block between the parent entry and the entry form.

Currently I didn't add CSS rules to make the parent entry and the prewiew more distinguishable. There are only the headings and the dotted hr-lines between the (maximal) three blocks.

For comparision:

The SelfHTML-forum, mentioned by Micha, has another order for the blocks. The order there is (from top to bottom): parent entry, entry form and the preview block below the entry form as last block and as part of the entry form. The submit button(s) are there located below the preview. Additionally there is another big difference. The preview is live rendered with JavaScript. That means, that when one inserts text in the textarea or in the input for the subject, this gets displayed immediately in the preview block.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

## A proposal for making the parent entry visible when replying

Hello,

And so it came, that I made a mockup of a new posting page. This proposal, if and when implemented, makes one of the arguments for keeping the preview-bubble-feature obsolete.

Looks fine for me. +1

The SelfHTML-forum [...] That means, that when one inserts text in the textarea or in the input for the subject, this gets displayed immediately in the preview block.

I believe it is an Ajax feature. Adding the input one-to-one to a preview block is quite simple. However, the input is formatted on the fly. That means in our case, the BB-code must be parsed.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

## A proposal for making the parent entry visible when replying

Hello,

The SelfHTML-forum [...] That means, that when one inserts text in the textarea or in the input for the subject, this gets displayed immediately in the preview block.

I believe it is an Ajax feature.

I don't know if Ajax/Fetch is in the game. I would assume, that there is no need for a server-client-communication, if the client side rendering works completely independent (with BB-code parsing, etc.). So yes, the feature in the SelfHTML-forum is made with JavaScript but maybe not with Ajax/Fetch.

Adding the input one-to-one to a preview block is quite simple. However, the input is formatted on the fly. That means in our case, the BB-code must be parsed.

To complete the description: this doesn't include code highlightning (because it is made on the server side (PHP lib GesHi)) but it should be able to parse the rest of the BB-codes.

- [b]
- [i]
- [link]
- [link=URL]
- [url]
- [url=URL]
- [color=HEXCODE]
- [size=small]
- [size=large]
- [list] with [*] [1]
- [img] with all its subfeatures
- [inlinecode]
- [code] respecting but not parsing the languages
- smileys as long as we want to support them for new entries (we have the much more powerful emoji support!)
- emojis

Tschö, Auge

[1]: I personally don't like the list implementation because it adds <br /> after closing </li>. This seems to be a limitation of the BB-code-parser-class or a misconfiguration in the parser definitions for lists. But that's my personal opinion and I don't know, what's to change.

--
Trenne niemals Müll, denn er hat nur eine Silbe!

## A proposal for making the parent entry visible when replying

Hello,

So yes, the feature in the SelfHTML-forum is made with JavaScript but maybe not with Ajax/Fetch.
To complete the description: this doesn't include code highlightning (because it is made on the server side (PHP lib GesHi)) but it should be able to parse the rest of the BB-codes.

At SELFHTML, syntax is highlighted in the preview. So, yes, it is possible to convert Geshi to JavaScript but I cannot believe that redundant code (PHP and JS) is used. So, I think the code is generated by the server and added via JavaScript. However, this is not the point for the proposal but maybe for the implementation...

[1]: I personally don't like the list implementation because it adds <br /> after closing </li>. This seems to be a limitation of the BB-code-parser-class or a misconfiguration

Maybe it is incomplete. If one compares the example code given in the documentation and our implementation there are some differences.

Documentation:

$bbcode->addParser ('list', 'bbcode_stripcontents');$bbcode->addCode ('list', 'simple_replace', null, array ('start_tag' => '<ul>', 'end_tag' => '</ul>'),
'list', array ('block', 'listitem'), array ());
$bbcode->addCode ('*', 'simple_replace', null, array ('start_tag' => '<li>', 'end_tag' => '</li>'), 'listitem', array ('list'), array ());$bbcode->setCodeFlag ('*', 'closetag', BBCODE_CLOSETAG_OPTIONAL);
$bbcode->setCodeFlag ('*', 'paragraphs', true);$bbcode->setCodeFlag ('list', 'paragraph_type', BBCODE_PARAGRAPH_BLOCK_ELEMENT);
$bbcode->setCodeFlag ('list', 'opentag.before.newline', BBCODE_NEWLINE_DROP);$bbcode->setCodeFlag ('list', 'closetag.before.newline', BBCODE_NEWLINE_DROP);

our implementation

  $bbcode->addParser ('list', 'bbcode_stripcontents');$bbcode->addCode ('list', 'simple_replace', null, array ('start_tag' => '<ul>', 'end_tag' => '</ul>'), 'list', array ('block', 'listitem', 'quote', 'rtl', 'ltr'), array ());
$bbcode->setCodeFlag ('list', 'paragraph_type', BBCODE_PARAGRAPH_BLOCK_ELEMENT);$bbcode->setCodeFlag ('list', 'closetag.after.newline', BBCODE_NEWLINE_IGNORE);
$bbcode->setCodeFlag ('list', 'opentag.before.newline', BBCODE_NEWLINE_DROP);$bbcode->setCodeFlag ('list', 'closetag.before.newline', BBCODE_NEWLINE_DROP);
$bbcode->addCode ('*', 'simple_replace', null, array ('start_tag' => '<li>', 'end_tag' => '</li>'), 'listitem', array ('list'), array ());$bbcode->setCodeFlag ('*', 'closetag', BBCODE_CLOSETAG_OPTIONAL);
// \$bbcode->setCodeFlag ('*', 'paragraphs', true);

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

## A proposal for making me not mixing up spam and ham functions

Hello

Because of an error I made while classifying the entries as spam or ham I deleted the replies in this thread. I am very sorry.

I opened an issue about the poor distinctiveness of the ham- and spam-links and their confirmation pages two weeks ago and then "it" happened yesterday. I accidently deleted all initial replies to the opening entry of this thread . That made me hurrying with thinking about a solution.

In the issue Micha proposed to merge the ham and spam classification links in the adminstration block under every entry into one link and the corresponding confirmation pages into one page for both purposes.

"Maybe a solution is to join both options to "spam/ham". The decision is then made only on the following page by a group of radio buttons."

Even I tend to keep the buttons for not cluttering the feature with additional steps to take I gave it a try (currently without the proposed radio buttons). I made a non-functional mockup for this feature in a first step. Keep in mind, that this mockup is unfinished. Neither the colours nor the layout is fixed. Additionally we need further distinction features and clarity about the wording, order of the blocks and possible accentuation of some of the buttons.

The mockup is prepared to work on tiny and great displays (a.k.a. is responsible) even this is also in an unfinished state.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

## A proposal for making me not mixing up spam and ham functions

Hello,

I would arrange both blocks below each other. The option "Delete only" is redundant and can be omitted in my opinion.

All in all, ich think it is an improvement to join both options.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

## A proposal for making me not mixing up spam and ham functions

Hello

I would arrange both blocks below each other.

Hmm, for narrow viewports it is implemented that way but for wide viewports this looks a bit odd. I changed the CSS-rule to display the blocks one below the other in my browsers web developer tools (WDT).

As you can see [1], I also removed the "Delete only"-button in the spam section for the screenshot with the WDT. The viewport has a width of roughly 1800 pixels, the content is no zoomed (in the browser) and my browser has a default font size of 16 pixels which is applied here.

That way there remains a lot of empty space. I don't know if this is desirable.

The other thing is, that the icons, I used for the mockup, are the default icons with dimensions of roughly 16 to 16 pixels (or lesser). They are blown up to much more than 200% of their original size, what looks bad.

So the chain of things to do gets another chain link, the overhaul of the icon set with larger versions of the current set (if the original set is still avaliable in a larger version), a new, different pixel based set with a much higher resolution or with a SVG-based set. I (for myself) prefer a solution with SVG icons.

My own set is not the beautiest, I can imagine, it is not really consistent in its style and it differs clearly from the current set. The latter may be desirable or not.

There are several sources for more consistent icon sets with free licenses, where we would be able to generate SVG-based exports. Most of these sets are unicoloured, what would be a huge optical change. On the other hand it would give us the possibility to apply it i.e. to buttons (or other elements) in the text color with the feature to change the colour when hovering the element (if the element is interactive).

The option "Delete only" is redundant and can be omitted in my opinion.

ACK

All in all, ich think it is an improvement to join both options.

Tschö, Auge

[1]: *btw* The uploaded screenshot is saved in the WebP-format what shrinked the file size of the image from the already small amount of 38kB of the PNG-image to 15kB.

--
Trenne niemals Müll, denn er hat nur eine Silbe!

## A proposal for making me not mixing up spam and ham functions

Hello,

I think, we should reduce the redundant text. In my opinion this text is enough:

Please flag and report this entry only if the content is sufficient to train the filter! The spam filters are founded by the Bayes-theorem. Based on training data, the probability of an entry to be spam is estimated. Wrong classifications result in an insensitive filter.

() I want to keep this entry (HAM)
() I want to delete this entry because it contains unwanted content. (SPAM)
[] Use entry to train the filter.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

## SVG icons

Hello,

There are several sources for more consistent icon sets with free licenses, where we would be able to generate SVG-based exports. Most of these sets are unicoloured, what would be a huge optical change. On the other hand it would give us the possibility to apply it i.e. to buttons (or other elements) in the text color with the feature to change the colour when hovering the element (if the element is interactive).

I don't have a problem to replace the png by svg graphics. And I don't have a problem, if the icons don't look like the old ones. So, feel free to transfer the icons to a more modern style.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences