Feature #27758

Adds preview option to the wiki toolbar

Added by Marius BALTEANU 7 months ago. Updated about 1 month ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:UI
Target version:4.1.0
Resolution:

Description

I'm working on a patch that adds the Preview functionality to the wiki toolbar. I find it more friendly to have the preview option for each individual field, instead of the bottom link. Most of the time, when I'm writing the description of an issue, I need to scroll down to the preview link, click it, view the preview and then scroll up to continue writing.

I want to share some screenshoots in order to take some feedback from the community.

1. Write/Preview tabs:

When the preview tab is opened, the textarea field is replaced with the formatted text. In this way, you can easily switch between write/preview modes.

2. Preview button

Instead of the tabs, we can have just a button that toggles between Preview and Write.

write_preview.png (67.9 KB) Marius BALTEANU, 2017-12-07 21:12

preview.png (66.6 KB) Marius BALTEANU, 2017-12-07 21:36

write.png (68.9 KB) Marius BALTEANU, 2017-12-11 19:21

preview.png (66.2 KB) Marius BALTEANU, 2017-12-11 19:21

27758-many-lines.png (114 KB) Go MAEDA, 2017-12-12 02:54

drop-jstoolbar-textile.min.patch Magnifier (11.2 KB) Marius BALTEANU, 2018-01-08 20:01

write.png (102 KB) Marius BALTEANU, 2018-01-26 21:10

preview.png (76.1 KB) Marius BALTEANU, 2018-01-26 21:10

27758-padding@2x.png (18.1 KB) Go MAEDA, 2018-04-23 11:38

preview_with_padding.png (69.7 KB) Marius BALTEANU, 2018-04-23 21:32

write-20180429@2x.png (8.83 KB) Go MAEDA, 2018-04-29 10:10

preview2-20180429@2x.png (6.81 KB) Go MAEDA, 2018-04-29 10:10

preview1-20180429@2x.png (6.81 KB) Go MAEDA, 2018-04-29 10:10

replace_preview_link_with_write_preview_tabs.patch Magnifier (40.5 KB) Marius BALTEANU, 2018-04-30 13:20


Related issues

Related to Redmine - Patch #27368: Make preview for comments for news New
Related to Redmine - Feature #2604: Preview comment on news / bulk edit New 2009-01-28
Related to Redmine - Feature #22015: A side by side textile preview would by very helpful New
Related to Redmine - Feature #9174: Suggestion - Preview on Documents New 2011-09-02
Related to Redmine - Feature #7157: Content Editor Preview at the same place where text is New 2010-12-22
Related to Redmine - Feature #4252: Move preview button to before "submit" New 2009-11-20

History

#1 Updated by Marius BALTEANU 7 months ago

  • Subject changed from Adds preview tab to the wiki toolbar to Adds preview option to the wiki toolbar

#2 Updated by Holger Just 7 months ago

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!

#3 Updated by Marius BALTEANU 7 months ago

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.

#4 Updated by Marius BALTEANU 6 months ago

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:

Preview tab:

#5 Updated by Go MAEDA 6 months ago

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.

#6 Updated by Marius BALTEANU 6 months ago

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.

#7 Updated by Mischa The Evil 6 months ago

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:
  • Preview tab:
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.

#8 Updated by Marius BALTEANU 6 months ago

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

#9 Updated by Marius BALTEANU 5 months ago

  • Related to Patch #27368: Make preview for comments for news added

#10 Updated by Marius BALTEANU 5 months ago

  • Related to Feature #2604: Preview comment on news / bulk edit added

#11 Updated by Marius BALTEANU 5 months ago

  • Related to Feature #22015: A side by side textile preview would by very helpful added

#12 Updated by Marius BALTEANU 5 months ago

  • Related to Feature #9174: Suggestion - Preview on Documents added

#13 Updated by Marius BALTEANU 5 months ago

  • Related to Feature #7157: Content Editor Preview at the same place where text is added

#14 Updated by Marius BALTEANU 5 months ago

  • Related to Feature #4252: Move preview button to before "submit" added

#15 Updated by Marius BALTEANU 5 months ago

  • File deleted (replace_preview_link_with_a_write_preview_tabs.patch)

#16 Updated by Marius BALTEANU 5 months ago

  • File deleted (write_preview_tabs_wip.patch)

#17 Updated by Marius BALTEANU 5 months ago

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:

Preview tab:

#18 Updated by Marius BALTEANU 5 months ago

  • File replace_preview_link_with_write_preview_tabs.patch added

#19 Updated by Bernhard Rohloff 5 months ago

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.

#20 Updated by Mischa The Evil 5 months ago

  • Assignee set to Marius BALTEANU
  • Target version set to Unplanned

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?

#21 Updated by Marius BALTEANU 5 months ago

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

#22 Updated by Bernhard Rohloff 5 months ago

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 4.0.0 or 4.1.0.

#23 Updated by Mischa The Evil 5 months ago

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

1 like "Lesyuk, Andriy (2013). Mastering Redmine. Packt Publishing. ISBN 978-1-849519-14-4.", although I don't know if it changed with its second edition.

#24 Updated by Bernhard Rohloff 5 months ago

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.

#25 Updated by Marius BALTEANU 2 months ago

@Go Maeda, is something missing from my patch in order to set the target version to 4.1.0? I really want to see this change in the next major release.

#26 Updated by Go MAEDA 2 months ago

  • File 27758-padding@2x.png added
  • Target version changed from Unplanned to Candidate for 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?

#27 Updated by Marius BALTEANU 2 months ago

Thanks for your feedback.

Now is better?

#28 Updated by Go MAEDA 2 months ago

Marius BALTEANU wrote:

Now is better?

It looks nice.

#29 Updated by Marius BALTEANU about 1 month ago

  • File deleted (replace_preview_link_with_write_preview_tabs.patch)

#30 Updated by Marius BALTEANU about 1 month ago

  • File replace_preview_link_with_write_preview_tabs.patch added

Updated the patch to include the fix suggested by Go Maeda.

#31 Updated by Go MAEDA about 1 month ago

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:

"Preview" tab (the current patch):

"Preview" tab (padding-top: 0):

.tabular .wiki-preview p {
  min-height: initial;
  padding: 1em 0 1em 0 !important;
  overflow: initial;
}

#32 Updated by Marius BALTEANU about 1 month ago

Attached the fixed version. Sorry for my previous patch, I've totally messed up the CSS rules (I wrote margin instead padding).

#33 Updated by Marius BALTEANU about 1 month ago

  • File deleted (replace_preview_link_with_write_preview_tabs.patch)

#34 Updated by Go MAEDA about 1 month ago

  • Assignee deleted (Marius BALTEANU)
  • Target version changed from Candidate for next major release to 4.1.0

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

Also available in: Atom PDF