--------------------------------------------------------------------------------
I really like this proposal as it makes it much more apparent when a preview is available. Using a tab directly besides the respective text field helps users to not lose focus of their work.

UI-wise, I like the tab-approach (your first screen shot) mich better than the button since the tabs make it clear that you change between different views of the same thing (the entered text). This idiom is also common in other software like GitHub or Wordpress. I'd like to propose some slight changes though:

* We should use the exact visual design of the existing tabs elements already used elsewhere, e.g. in the revision view of the repository where it's possible to switch between the list of changes and the diff or the project's settings tab.
* I think those edit icons above the text box should be part of the the "Write" tab itself so that they are removed when you switch to the "Preview" tab. Here, we might need to be a bit creative since it is probably desirable to not introduce another "row" of text (tab, icons, tex box). It might be possible to combine the icons and the tabs somehow while still sticking to the existing components used elsewhere in Redmine.

Generally, the layout should also work when there is no explicit preview option for the text box available since this might not strictly be the case for all fields; the welcome text in the settings comes to mind, as well as e.g. text custom fields or stuff added by plugins. It would however be awesome if this preview / tab bar would be as versatile as the existing icon bar, preferably it could even be added with exactly the same code (or just small changes).

All in all though, I like this very much!
--------------------------------------------------------------------------------
Holger Just wrote:
> I really like this proposal as it makes it much more apparent when a preview is available. Using a tab directly besides the respective text field helps users to not lose focus of their work.
Thanks for your feedback, Holger.

> UI-wise, I like the tab-approach (your first screen shot) mich better than the button since the tabs make it clear that you change between different views of the same thing (the entered text). This idiom is also common in other software like GitHub or Wordpress. I'd like to propose some slight changes though:
>
> * We should use the exact visual design of the existing tabs elements already used elsewhere, e.g. in the revision view of the repository where it's possible to switch between the list of changes and the diff or the project's settings tab.
Totally agree.
> * I think those edit icons above the text box should be part of the the "Write" tab itself so that they are removed when you switch to the "Preview" tab.
Yes, I've already implemented this feature.
> Here, we might need to be a bit creative since it is probably desirable to not introduce another "row" of text (tab, icons, tex box). It might be possible to combine the icons and the tabs somehow while still sticking to the existing components used elsewhere in Redmine.
For now, I chose to create the tabs from javascript, in the same way how the toolbar buttons are created and most of the changes are made in the jstoolbar.js file. If you think that is better to create the tabs using the existing @render_tabs@ method, I think that I can find a solution.

> Generally, the layout should also work when there is no explicit preview option for the text box available since this might not strictly be the case for all fields; the welcome text in the settings comes to mind, as well as e.g. text custom fields or stuff added by plugins. It would however be awesome if this preview / tab bar would be as versatile as the existing icon bar, preferably it could even be added with exactly the same code (or just small changes).
In the current implementation, the Preview works wherever the @wikitoolbar_for@ method is called because I've added a default method @preview#text@.

> All in all though, I like this very much!

I'm going to post this weekend a fist version of my patch and I think that we can discuss more about the technical solution after that.

--------------------------------------------------------------------------------
Holger, attached is an working version (only for markdown) of my patch. I still have some things to do (like adding support for textile, removing preview links, add tests), but if you're interested to test it, is enough. The functionality and the design are the final one (attached also 2 screenshots). I'm not 100% happy which the results from UI perspective, but is the best that I can do which my current CSS skills, using the existing Redmine components and not adding to many changes.

Any feedback is really appreciated. My intention is to have a final version of this patch until 21.12.

Write tab:
!write.png!

Preview tab:
!preview.png!
--------------------------------------------------------------------------------
Thank you for working on this feature. I think that this is an awesome improvement.

But I noticed that the preview is not perfectly displayed when I enter text with many lines. Maybe we need a vertical scroll bar or a responsive preview area.

!27758-many-lines.png!
--------------------------------------------------------------------------------
Go MAEDA wrote:
> But I noticed that the preview is not perfectly displayed when I enter text with many lines. Maybe we need a vertical scroll bar or a responsive preview area.

Thanks. I've fixed the issue on my local development.
--------------------------------------------------------------------------------
I'll start by saying that I'm also in favor of an overall change as here proposed. That said, I just came around another UI-wise slightly similar plugin implementation (mostly done using JavaSCript), where seeing its screenshots reminded me about this issue: https://github.com/tleish/redmine_editor_preview_tab. The respective screenshots:
* Write tab:
!https://raw.githubusercontent.com/tleish/redmine_editor_preview_tab/master/docs/screenshot_write.png!

* Preview tab:
!https://raw.githubusercontent.com/tleish/redmine_editor_preview_tab/master/docs/screenshot_preview.png!

Comparing the plugin with your implementation as of note#4 (further referred to as '[the] patch':
* I think that a UI-design like provided by your patch is preferred, for the same reasons as mentioned by Holger in note#2;
* your patch is already more complete/polished (think e.g. access-keys);
* your patch is a bit less JavaScript heavy;
* your approach of implementing this in a similar fashion as (other) toolbar buttons is interesting, creative and (visually) neat.

Nice job. I'm interested in seeing subsequent iterations of this patch.
--------------------------------------------------------------------------------
I've finished most of the work for this feature. UI tests are missing currently, but I'll add a new patch with them next days. Until then, the patches can be tested and/or reviewed.

*1. drop-jstoolbar-textile.min.patch:*
This patch removes the jstoolbar-textile.min.js file and uses for textile formatting the same jstoolbar.js file. I chose to remove this file because I wasn't able to figure out which is the "official" way to generate a new merged and minified version from the new jstoolbar. In the same time, if it is desired to use a minified version (which is a good idea), we should document the tools and the steps to generate it and we should apply the same logic also for markdown formatting (at least).

*2. replace_preview_link_with_a_write_preview_tabs.patch:*
- adds the write preview tabs to the text formatting toolbar
- removes all the existing Preview links
- adds a default preview url that can be used to preview simple texts (eg: project description from the project settings)
- on responsive mode, when the screen resolution width in less than the total width of the js toolbar (tabs + buttons), some buttons become hidden. I'm not happy with the current solution, but is not a blocker from my point of view and we can improve this later when we have a better solution.

Considering that the changes are quite big, I think that it is a good opportunity to discuss the implementation of this feature in Redmine version:"4.0.0".
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Attached is a new version of the patch which includes:
- fixes for the existing tests
- new system tests for the write/preview feature in various screens
- small fixes

This version of the patch is final from my point of view.

Some screenshots:

Write tab:
!write.png!

Preview tab:
!preview.png!
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
I've played around with your latest patches and I haven't found any flaw, or unexpected behavior. Except for the missing accesskey 'r' to switch to the preview.
It's definitely better than the mentioned plugin which I have installed on my private Redmine and a great improvement to Redmine's UX.

I'm looking forward to see this merged, soon.
--------------------------------------------------------------------------------
Marius BALTEANU wrote:
> *1. drop-jstoolbar-textile.min.patch:*
> This patch removes the jstoolbar-textile.min.js file and uses for textile formatting the same jstoolbar.js file. I chose to remove this file because I wasn't able to figure out which is the "official" way to generate a new merged and minified version from the new jstoolbar. In the same time, if it is desired to use a minified version (which is a good idea), we should document the tools and the steps to generate it and we should apply the same logic also for markdown formatting (at least).

I agree completely on this. See eg. #14937 where this became troublesome too.

Bernhard Rohloff wrote:
> [...] Except for the missing accesskey 'r' to switch to the preview.

This seemed to be working in the patch I -reviewed- +looked at+ as posted in note#4.
@Marius: can you take a look at this?

--------------------------------------------------------------------------------
@Bernhard, thanks for testing these patches.

Regarding the missing accesskey 'r', I'm aware, but I can't make it work correctly (using only the native accesskey attribute) when we have more than one JS Toolbar in the page (like in the issue#edit mode). Hitting the 'r' key when the focus is in the textarea, will switch the preview tab from the next JS Toolbar because is the next element in the page that has the respective accesskey. To make it more clear, look at the HTML structure (illustrated below) from the issue#edit and observe that the textarea is always after its own Preview element.
* ...
* write tab
* preview tab with accesskey 'r'
* textarea for description field
* ...
* write tab
* preview tab with accesskey 'r'
* textarea for notes field

To make it work as expected, I need to override the native functionality using javascript, but this is something bigger and I want to do it in the future because:
- I would like to add some shortcuts for accessing the jstoolbar buttons (Control/Command + B for bold, Control/Command + I for italic, etc..).
- I will propose to use a JS library that implements a consistent shortcut key between the browsers. I find it very difficult to use the current implementation that depends on the browser and OS.

From my point of view, this missing accesskey should not be a blocker for this ticket.

--------------------------------------------------------------------------------
I think the missing accesskey is no big deal, because this patch lets you access the previews easier than the mostly unknown accesskey did. I also injected the accesskey in the tab with the development tools of Firefox to get a feeling for the UX and it wasn't good overall. You have no possibility to switch back to the editor tab via accesskey so you have to use the mouse anyway.

It would be great if we could get this merged in version:4.0.0 or version:4.1.0.

--------------------------------------------------------------------------------
Marius BALTEANU wrote:
> [...] (using only the native accesskey attribute) [...]

Yeah, I consider them as pretty rudimentary ;)

Marius BALTEANU wrote:
> - I would like to add some shortcuts for accessing the jstoolbar buttons (Control/Command + B for bold, Control/Command + I for italic, etc..).
> - I will propose to use a JS library that implements a consistent shortcut key between the browsers. I find it very difficult to use the current implementation that depends on the browser and OS.

Both sound good, but especially the second is something that could help wide(r) adoption of accesskey use. The current dependency on browser and OS (by using the native attribute) is pretty horrific, if you'd ask me.
Though, I'd like to know first (as in before applying code that is knowingly breaking the preview accesskey functionality) if Jean-Philippe would accept any patches implementing accesskeys using JS at all.

Btw: issue #6846 is related to this.

Marius BALTEANU wrote:
> From my point of view, this missing accesskey should not be a blocker for this ticket.

I tend to agree in this case. However we should not forget that this particular accesskey has been available for over 10 years (since 0.6), so users could be very accustomed to it, making it a potentially hard change (like we've seen too with e.g. #19468, which, partially, obsoleted the 'Start calendars on' setting).

Bernhard Rohloff wrote:
> [...] the mostly unknown accesskey [...]

Well, I _think_ this statement is mostly true, but we can't say for sure. The only fact that we know of is that the feature has been long available but that it never has been documented properly before #27412 (it's not even covered in popular English books[1]). I know Redmine admins, superusers and a small amount of managers (i.e. people who actually read the source code) who have been actively advocating to their users to make use of these accesskeys to up their productivity...

fn1. like "Lesyuk, Andriy (2013). _Mastering Redmine_. Packt Publishing. ISBN "978-1-849519-14-4":https://en.wikipedia.org/wiki/Special:BookSources/978-1-849519-14-4.", although I don't know if it changed with its second edition.

--------------------------------------------------------------------------------
Mischa The Evil wrote:
> Though, I'd like to know first (as in before applying code that is knowingly breaking the preview accesskey functionality) if Jean-Philippe would accept any patches implementing accesskeys using JS at all.

Yes, I agree. It would be great to have JP's opinion/vision on this topic.

I'm a heavy user of the shortcuts, too. And although I would miss this feature, I think this patch would gain the productivity of the majority of users who are not so familiar with the accesskeys. One can have a quick look at the preview without scrolling the page up and down. The editor always stays in its position which is also less distracting.

--------------------------------------------------------------------------------
@Go Maeda, is something missing from my patch in order to set the target version to version:4.1.0? I really want to see this change in the next major release.
--------------------------------------------------------------------------------
Marius, thank you for working on this feature, I think it is a big improvement.

But there is one worrisome thing. Please see the following screenshot. I think we can improve padding value. 1em of padding before the first line is too much. And the left side of the paragraph is too close to the border on the left. What do you think?

!{width: 592px; border: 1px solid #ccc;}.27758-padding@2x.png!
--------------------------------------------------------------------------------
Thanks for your feedback.

Now is better?

!preview_with_padding.png!
--------------------------------------------------------------------------------
Marius BALTEANU wrote:
> Now is better?
>
> !preview_with_padding.png!

It looks nice.
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Updated the patch to include the fix suggested by Go Maeda.
--------------------------------------------------------------------------------
Marius BALTEANU wrote:
> Updated the patch to include the fix suggested by Go Maeda.

Thanks. I think it will be perfect if the padding-top in the preview area is dropped. Please see the screenshots.

*"Write" tab:*
!{width: 200px; border: 1px solid #ccc}.write-20180429@2x.png!

*"Preview" tab (the current patch):*
!{width: 200px; border: 1px solid #ccc}.preview1-20180429@2x.png!

*"Preview" tab (padding-top: 0):*
!{width: 200px; border: 1px solid #ccc}.preview2-20180429@2x.png!

<pre>
.tabular .wiki-preview p {
min-height: initial;
padding: 1em 0 1em 0 !important;
overflow: initial;
}
</pre>
--------------------------------------------------------------------------------
Attached the fixed version. Sorry for my previous patch, I've totally messed up the CSS rules (I wrote margin instead padding).
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Thank you for attaching the final patch. I suggest implementing this feature in the next release.

* attachment:0001-drop-minified-version-of-jstoolbar-textile.patch
* attachment:0002-replace-preview-link-with-write-priview-tabs.patch
--------------------------------------------------------------------------------
Would love to see this patch included. It would make it much easier less hacky to handle previews in alternative editors like "Bestest Markdown Editor":http://www.redmine.org/plugins/bestest_markdown_editor, which also integrates the preview view inside the editor.

Would it also add preview support for @textarea@ elements that currently do not have a preview option, like when editing the issue description?

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Updated the patches to apply cleanly on the current trunk and to prevent an error on IE browser.

Martin Blom wrote:
> Would love to see this patch included. It would make it much easier less hacky to handle previews in alternative editors like "Bestest Markdown Editor":http://www.redmine.org/plugins/bestest_markdown_editor, which also integrates the preview view inside the editor.
>
> Would it also add preview support for @textarea@ elements that currently do not have a preview option, like when editing the issue description?

Yes, it will work anywhere the toolbar is now rendered because the Write/Preview tabs are part of the toolbar.

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Patch committed for 4.0. Marius, thank you for your work on this.
--------------------------------------------------------------------------------
Jean-Philippe Lang wrote:
> Patch committed for 4.0. Marius, thank you for your work on this.

Thanks for committing it. I'll keep an eye on possible issues reported by the users.
--------------------------------------------------------------------------------
Write and Preview are hardcoded strings in javascript. We have to support translations for these.
--------------------------------------------------------------------------------
I'm fixing the issue right now.
--------------------------------------------------------------------------------
I've looked in the code and support for translations already exists, please see line source:/trunk/public/javascripts/jstoolbar/jstoolbar.js#L101. The @jsTab@ function receives the tab name as a string and it checks first for translation. If exists, it uses the translated string, if not, it uses the string as tab name.

I think we need to add the new strings (Write, Previews) to all translations files. This is a manual process or there is a task to automatically add them?
--------------------------------------------------------------------------------
Jean-Philippe Lang wrote:
> Write and Preview are hardcoded strings in javascript. We have to support translations for these.

Is "Edit" not better then "Write"?
--------------------------------------------------------------------------------
Marius BALTEANU wrote:
> I think we need to add the new strings (Write, Previews) to all translations files. This is a manual process or there is a task to automatically add them?

Add keys to @en.yml@ and run @rake locales@.
--------------------------------------------------------------------------------
Wim DePreter wrote:
> Jean-Philippe Lang wrote:
> > Write and Preview are hardcoded strings in javascript. We have to support translations for these.
>
> Is "Edit" not better then "Write"?

Yes, we can reuse Edit and Preview strings that are already present in locales.
--------------------------------------------------------------------------------
Marius BALTEANU wrote:

> I think we need to add the new strings (Write, Previews) to all translations files. This is a manual process or there is a task to automatically add them?

I guess you're speaking about JS translations that sit in public/javascripts/jstoolbar/lang. There's no task to add strings to these. You can just update english and I'll take care of the others. Thanks.
--------------------------------------------------------------------------------
Here it is. I choose to replace also in the code Write with Edit.
--------------------------------------------------------------------------------
I didn't see that the en locale was already filled in your original patch, thanks. I've updated all the others.
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Toolbar buttons are not wrapped when the screen is narrow.

*Redmine 4.0*

!toolbar-4.0.png!

*Redmine 3.4*

!toolbar-3.4.png!
--------------------------------------------------------------------------------
Takeshi Nakamura wrote:
> Toolbar buttons are not wrapped when the screen is narrow.

Marius, could you look into this?
--------------------------------------------------------------------------------
Go MAEDA wrote:
> Takeshi Nakamura wrote:
> > Toolbar buttons are not wrapped when the screen is narrow.
>
> Marius, could you look into this?

I know the issue, I've mentioned about this in note-8 ("- on responsive mode, when the screen resolution width in less than the total width of the js toolbar (tabs + buttons), some buttons become hidden. I'm not happy with the current solution, but is not a blocker from my point of view and we can improve this later when we have a better solution." but I'm not sure which should be the fix because the proposed solution will require a lot of space on small screens and also is not an easy fix.

A quick fix could be to hide the JS toolbar on small screens and on the long term, we can work to a better solution, for example:
* group some JS buttons under the same category: (eg: H1, H2 and H3 under H category)
* option to expand/collapse the JS buttons
* horizontal scroll without showing the scroll bar
* left/right buttons (as we have for menu)

IMHO, we can deliver this as it is and we'll fix it in the next minor release when for sure we will have other small improvements to be done for this feature.

--------------------------------------------------------------------------------
Marius BALTEANU wrote:
> IMHO, we can deliver this as it is and we'll fix it in the next minor release when for sure we will have other small improvements to be done for this feature.

I agree with you. Since it is a small issue, it should not delay the release of 4.0.0.
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

relates,Closed,27368,Make preview for comments for news
relates,Closed,2604,Preview comment on news / bulk edit
relates,Closed,22015,A side by side textile preview would by very helpful
relates,Closed,9174,Suggestion - Preview on Documents
relates,Closed,4252,Move preview button to before "submit"
relates,New,29694,Some buttons in wiki toolbar are hidden in responsive layout
relates,Closed,29712,Preview and wiki toolbar for full width custom fields
relates,Closed,30988,Preformatted text overflows the preview area
relates,Closed,30758,Preview URL in Wiki Toolbar should be escaped
relates,Closed,30459,Switch edit/preview tabs with keyboard shortcuts
relates,Closed,34444,Remove unused key :preview from Redmine::AccessKeys::ACCESSKEYS
duplicates,Closed,7157,Content Editor Preview at the same place where text is