better wiki preview

[anonymous]

The editor would be better at top of the page instead of end of the page when take a page preview.

The second suggestion is an AJAX preview instead of realoding the whole page, like this:

​http://www.jspwiki.org/Edit.jsp?page=JSPWikiFAQ

click on "sneak preview" checkbox

[psycho]

+1''' I agree with that, preview would be better below editor! About AJAX, why not, but to my mind it's less important. (no link with the current topic, but your spam filter is maybe a little too hard, no?)

[Christian Boos]

I have a wide-screen side-by-side wiki editor patch somewhere ;-)

MoinMoin and Wikipedia both have preview below the textarea, maybe we can start doing the same?

+------------------------------------------+
| the textarea ...                         |
| ...                                      |
| ...                                      |
|                                          |
+------------------------------------------+

Comment |__________________________________|

[Preview] [Review]    [Submit] [Cancel]

+- Preview (edit) -------------------------+
|                                          |
|                                          |
|                                          |
|                                          |
|                                          |
|                                          |
|                                          |
|                                          |
|                                          |
|                                          |
|                                          |
|                                          |
+------------------------------------------+

Clicking on Preview or Review will take you to the Preview (edit) level. There will be less scrolling that way, I think.

[Remy Blank]

And while you're doing that, please also drop the <fieldset> around the preview, as it's responsible for the same "overflow" effect as we had for tickets :)

[Christian Boos]

Enhanced TracWiki editor, patch on r8859

[Christian Boos]

In the above patch, the normal wiki edit mode has been modified as requested in this ticket so that the preview follows the textarea and the controls (as in comment:2).

What's even more interesting is the new Edit side-by-side checkbox that you can see next to the textarea height selector.

In this mode, the textarea and the preview are shown side-by-side while editing. This avoids entirely the need to jump back and forth between the preview and the editor while editing a page. This is especially useful during review editing, so that you can read the page and make fixes as you go, which is very effective. I believe this is a major enhancement, and it works fine even on a reduced 800x600 size, as it feels like a two column page.

I've tested and fine tuned the above patch quite a lot, so it's ready to take more feedback! In the meantime, I already see a few things to enhance, like the top/bottom links currently modeled after the ticket ones. The main problem with that is in side-by-side preview-right mode (the current default), where the action link is in the upper right corner and leads you to the bottem left corner, it's not optimal.

[Remy Blank]

Nice! Putting the preview at the bottom indeed makes sense. The side-by-side view is great, and contrary to what I thought, the text usually lines up more or less between the textbox and the preview.

A few suggestions:

• About the top/bottom links, in the ticket view the arrow is after the text, whereas in this patch, it's before. We should be consistent about that (use either one, I don't mind).

• Can we make the "Edit side-by-side" checkbox dynamic? That is, make it switch between both views without having to press the "Preview" button?

• Can we throw some AJAX into the mix and have the preview update automatically after the user has stopped making changes to the <textarea> for e.g. 2 seconds?

Even without considering my comments above, a big +1 from me!

(Slightly OT: thinking about AJAX, we could use the same trick when entering a ticket comment, and display it as the user types. That would be pretty awesome, and cure those people too lazy to hit "Preview". Mmh… I might just give this a try.)

[Christian Boos]

Replying to rblank:

Nice! Putting the preview at the bottom indeed makes sense. The side-by-side view is great, and contrary to what I thought, the text usually lines up more or less between the textbox and the preview.

Yes, and if they don't line up naturally, it's usually because of line wrapping. This means there are more visible lines than real lines, and as the latter is used to set the height of the textarea, there will be a scrollbar and you can use it (or the mousewheel) to adjust the alignment as you go.

A few suggestions:

• About the top/bottom links, in the ticket view the arrow is after the text, whereas in this patch, it's before. We should be consistent about that (use either one, I don't mind).

I'm not satisfied of either, actually. Please try the follow-up patch, which makes use of top/bottom arrows only. The character entities are used for "rapid prototyping", if you like the approach, we should replace them with nice up/down arrow icons, for consistent look across browsers.

• Can we make the "Edit side-by-side" checkbox dynamic? That is, make it switch between both views without having to press the "Preview" button?

Should be possible, yes.

• Can we throw some AJAX into the mix and have the preview update automatically after the user has stopped making changes to the <textarea> for e.g. 2 seconds?

He he, yes, that was the plan ;-) However, that's something which should make sense in the side-by-side mode only. In normal sequence mode, except for very brief texts, chances are that the rendering of what you're typing will be off-screen.

Even without considering my comments above, a big +1 from me!

Thanks! I'm glad you liked it.

(Slightly OT: thinking about AJAX, we could use the same trick when entering a ticket comment, and display it as the user types. That would be pretty awesome, and cure those people too lazy to hit "Preview". Mmh… I might just give this a try.)

With the caveat about the length of wiki texts given above… Unless you're thinking of a side-by-side mode for ticket comments as well ;-)

[Christian Boos]

Alternative page navigation approach (patch on top of t8721-enhanced-wiki-editor.patch​)

[Christian Boos]

More about nav-tweaks.patch​:

So the rationale of the intra-page navigation links is to have "shortcuts" to minimize the mouse moves.

If we place them on the right side, then we have the following problems:

• it's a bit redundant with the scrollbar
• on the upper right, it's too close to the contextual navigation links; I find that visually confusing
• if the target at the bottom of the page is on the lower left (like the controls are in sequence mode), you have the "diagonal effect" (need to move from upper right of the screen to the lower left)

Putting the shortcuts on the left side suppress those inconveniences plus would be consistent with other (future) usage of mouse shortcuts (#6424).

Also, placing the arrow after the title would somehow conflict with the ¶ link one expects to find after section titles (even if those sections don't actually have the link).

[Christian Boos]

Yet another tweak to the alternative page navigation approach (patch on top of t8721-enhanced-wiki-editor.patch​). Now the rendering of up arrow shown in the form for the side-by-side mode is consistent with the other arrows.

[Christian Boos]

Replying to cboos:

Replying to rblank: … the text usually lines up more or less between the textbox and the preview.

… there will be a scrollbar and you can use it (or the mousewheel) to adjust the alignment as you go.

Oh, and in case the textarea is shorter than the preview, the usability greatly depends on the capacity of the browser to allow you to resize the textarea… This gives an edge to WebKit-based browsers for now (and yet another incentive for #8216).

[Remy Blank]

Replying to cboos:

With the caveat about the length of wiki texts given above… Unless you're thinking of a side-by-side mode for ticket comments as well ;-)

The ticket comments usually are quite short, at least never as long as a complete wiki page. So I think the automatic preview does make sense there. I'm currently working on that, with the comment preview also placed below the <textarea> instead of above. You should be able to reuse the JavaScript code I'm writing ATM, I guess.

[Christian Boos]

In 8216-textarea-resize-r8859.patch​, I refreshed #8216's patch on top of nav-tweaks.2.patch​.

Works fine for me, even in iexplorer (ok IE8, but when using IE7 browser mode, it was OK as well). I just had to remove the textarea.focus(); call in endDrag(), as that would jump to the top of the textarea after the resize.

But now that this works, it makes me think that the textarea height could simply be made the same as the height of the preview ;-)

[Christian Boos]

Resizable textarea for all browsers, in javascript (Remy's patch from #8216, applying on top of nav-tweaks.2.patch​)

[Christian Boos]

But now that this works, it makes me think that the textarea height could simply be made the same as the height of the preview ;-)

Works great, see auto-resize-js.patch​. This also makes the Review changes mode much nicer in case the diff is short.

Now for the dynamic switch between normal and side-by-side mode, I'll wait for the feature to stabilize (a.k.a. landing on trunk), as the Javascript would have to dynamically alter all the things that are conditioned by the sidebyside flag in the template.

[Christian Boos]

Auto-resize textarea to be the same width as the preview, in side-by-side mode. Applies on 8216-textarea-resize-r8859.patch​.

[Christian Boos]

Ok, I realize that there are a bit too many patches here, so let's simplify things:

• cumulative patch implementing normal mode + side-by-side mode, on top of r8872: ticket8721-enhanced-wiki-editor-r8872.patch​
• the rest (automatic preview) will come after #8855

[Christian Boos]

TracWiki: enhanced wiki editor.

[Christian Boos]

Change page navigation links to be the same as for tickets, and try to make both prettier. Applies on top of ticket8721-enhanced-wiki-editor-r8872.patch​

[Christian Boos]

As a follow-up to the discussion in #8295, reworked-nav.patch​ is my last attempt for getting somehow clean and consistent page navigation links, in both the wiki editor and the ticket page.

[Christian Boos]

Ok, so the main enhancements to the wiki editor have been committed in r8888. Fine tuning of the intra-page navigation links committed in r8889.

In r8890, I adapted the ticket view to accommodate the trac-nav changes done in r8889.

[Remy Blank]

The improved wiki editor is really great!

I know you're going to hate me for that, but the in-page navigation links are still giving me trouble. In particular, their placement using em units is too sensitive to font size preferences in the browser. For example, I have quite a high resolution (1920x1200) so I have set a minimum font size of 15. This messes up the formatting, as you can see in the screenshots.

Wiki:

Ticket:

I understand the reason for setting a margin-top on the .trac-nav class (not being too close to the ctxtnav), but this is only necessary because the nav links contain text. How about using a single image?

I'm going to experiment a bit and hopefully propose something acceptable.

[Christian Boos]

The following makes it look better with big minimum sizes (tried 15 and 24):

trac/htdocs/css/ticket.css

@@ -82 +82 @@
 }
 
 #propertyform .trac-nav {
- margin-top: .5em;
+ margin-top: 2px;
 }
 #changelog { border: 1px outset #996; padding: 1em }
 .trac-shade { background-color: #eee }

trac/htdocs/css/trac.css

@@ -199 +199 @@
 .trac-nav {
  float: right;
  font-size: 80%;
- margin-top: 1.5em;
+ margin-top: 14px;
 }
 
 /* Alternate links */

[Christian Boos]

… but I'm OK to try the icon based solution as well ;-)

[Remy Blank]

Experiment using icons for intra-page navigation.

[Remy Blank]

Well, obviously I'm not a graphics designer, so this didn't turn out too well. Maybe I should have kept the background change on :hover.

Anyway, I wonder what the purpose of the following was (in trac.css):

#ctxtnav { height: 1em }

That's really the reason why we need a margin-top if we use text links. Ah, looking at the annotated file, it was to ensure that there's always some space between the navbar and the content. Maybe we should just change that to:

#ctxtnav { min-height: 1em }

and keep the text links without the margin-top.

[Remy Blank]

Use min-height instead of height for #ctxtnav.

[Remy Blank]

Yes, using min-height instead of height for #ctxtnav and dropping the margin-top on .trac-nav is my current favorite.

[Christian Boos]

ticket edit link with 8721-icon-navigation-r8891.patch​

[Christian Boos]

ticket edit link with 8721-ctxtnav-min-height-r8891.patch​

[Christian Boos]

wiki edit link with 8721-ctxtnav-min-height-r8891.patch​, firefox 3.5 and min font size of 15pt

[Christian Boos]

ticket edit link with margin-top specified in px (patch from comment:16)

[Christian Boos]

wiki edit link with margin-top specified in px (patch from comment:16), firefox 3.5 and min font size of 15pt

[Christian Boos]

Ok, my turn :-)

With the icons, we still have the positioning issue:

The arrow is too close to the context navigation links. Also, the rounded corners are not a good match to the other more "straight" icons we have elsewhere, e.g. the triangular expand/collapse ones.

With the min-height approach, it's still the same issue, the edit/preview links are too close to the context navigation links:

I find the comment:16 approach to be not so bad:

[Remy Blank]

Replying to cboos:

Also, the rounded corners are not a good match to the other more "straight" icons we have elsewhere, e.g. the triangular expand/collapse ones.

I said I was no graphics designer ;-)

With the min-height approach, it's still the same issue, the edit/preview links are too close to the context navigation links:

At least it doesn't overlap the context navigation links. I don't really mind their being right above one another, actually.

I find the comment:16 approach to be not so bad:

Right, it's the best appearance so far. I would still replace height with min-height for #ctxtnav, as that's what was really intended, and adjust the margins in comment:16 accordingly (if necessary).

Also, I would rather not set a margin-top for .trac-nav in trac.css, and set it explicitly for the cases where it's needed (in wiki.css and ticket.css. At the moment, you set an (arbitrary) margin in trac.css and undo it where it's not needed.

All right, that was my last comment on the subject. Whatever you do in the end will be fine for me :-)

[Christian Boos]

Replying to rblank:

Also, I would rather not set a margin-top for .trac-nav in trac.css, and set it explicitly for the cases where it's needed (in wiki.css and ticket.css. At the moment, you set an (arbitrary) margin in trac.css and undo it where it's not needed.

Final tweaks done in [8893]. I took an intermediate approach to use another class (.trac-topnav) for when the margin is needed.

Phew ;-)