Redmine

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.

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.

• Write tab:
  

• Preview tab:
  

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

Bernhard Ganslmeier, thanks for testing these patches.

• ...
• 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 4.0.0 or 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¹). 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...

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

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 4.1.0? I really want to see this change in the next major release.

Marius BALTEANU wrote:

Now is better?

It looks nice.

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

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.

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.

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.

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