Edgewall Software
Modify

Opened 8 years ago

Closed 8 years ago

#8721 closed enhancement (fixed)

better wiki preview

Reported by: anonymous Owned by: Christian Boos
Priority: normal Milestone: 0.12
Component: wiki system Version: none
Severity: major Keywords:
Cc:
Release Notes:
API Changes:

Description

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

Attachments (17)

t8721-enhanced-wiki-editor.patch (14.2 KB ) - added by Christian Boos 8 years ago.
Enhanced TracWiki editor, patch on r8859
nav-tweaks.patch (2.3 KB ) - added by Christian Boos 8 years ago.
Alternative page navigation approach (patch on top of t8721-enhanced-wiki-editor.patch)
nav-tweaks.2.patch (3.1 KB ) - added by Christian Boos 8 years ago.
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.
8216-textarea-resize-r8859.patch (15.0 KB ) - added by Christian Boos 8 years ago.
Resizable textarea for all browsers, in javascript (Remy's patch from #8216, applying on top of nav-tweaks.2.patch)
auto-resize-js.patch (1.4 KB ) - added by Christian Boos 8 years ago.
Auto-resize textarea to be the same width as the preview, in side-by-side mode. Applies on 8216-textarea-resize-r8859.patch.
ticket8721-enhanced-wiki-editor-r8872.patch (14.3 KB ) - added by Christian Boos 8 years ago.
TracWiki: enhanced wiki editor.
reworked-nav.patch (5.4 KB ) - added by Christian Boos 8 years ago.
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
nav-link1.png (13.9 KB ) - added by Remy Blank 8 years ago.
nav-link2.png (5.4 KB ) - added by Remy Blank 8 years ago.
nav-link3.png (12.6 KB ) - added by Remy Blank 8 years ago.
8721-icon-navigation-r8891.patch (5.4 KB ) - added by Remy Blank 8 years ago.
Experiment using icons for intra-page navigation.
8721-ctxtnav-min-height-r8891.patch (1.5 KB ) - added by Remy Blank 8 years ago.
Use min-height instead of height for #ctxtnav.
icon-navigation.png (4.6 KB ) - added by Christian Boos 8 years ago.
ticket edit link with 8721-icon-navigation-r8891.patch
min-height.png (4.4 KB ) - added by Christian Boos 8 years ago.
ticket edit link with 8721-ctxtnav-min-height-r8891.patch
min-height-wiki-ff-15pt.png (5.5 KB ) - added by Christian Boos 8 years ago.
wiki edit link with 8721-ctxtnav-min-height-r8891.patch, firefox 3.5 and min font size of 15pt
margin-top-14px.png (3.2 KB ) - added by Christian Boos 8 years ago.
ticket edit link with margin-top specified in px (patch from comment:16)
margin-top-wiki-ff-15px.png (4.5 KB ) - added by Christian Boos 8 years ago.
wiki edit link with margin-top specified in px (patch from comment:16), firefox 3.5 and min font size of 15pt

Download all attachments as: .zip

Change History (39)

comment:1 Changed 8 years ago by psycho

Severity: normaltrivial

+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?)

comment:2 Changed 8 years ago by Christian Boos

Keywords: consider added
Milestone: 0.12
Owner: set to 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.

comment:3 Changed 8 years ago by 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 :)

Changed 8 years ago by Christian Boos

Enhanced TracWiki editor, patch on r8859

comment:4 Changed 8 years ago by Christian Boos

Severity: trivialmajor

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.

comment:5 Changed 8 years ago by 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.)

comment:6 in reply to:  5 ; Changed 8 years ago by 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 ;-)

Changed 8 years ago by Christian Boos

Attachment: nav-tweaks.patch added

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

comment:7 Changed 8 years ago by 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).

Changed 8 years ago by Christian Boos

Attachment: nav-tweaks.2.patch added

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.

comment:8 in reply to:  6 Changed 8 years ago by 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).

comment:9 in reply to:  6 Changed 8 years ago by 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.

comment:10 Changed 8 years ago by Christian Boos

Keywords: consider removed

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 ;-)

Changed 8 years ago by Christian Boos

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

comment:11 in reply to:  10 Changed 8 years ago by 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.

Changed 8 years ago by Christian Boos

Attachment: auto-resize-js.patch added

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

comment:12 Changed 8 years ago by Christian Boos

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

Changed 8 years ago by Christian Boos

TracWiki: enhanced wiki editor.

Changed 8 years ago by Christian Boos

Attachment: reworked-nav.patch added

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

comment:13 Changed 8 years ago by 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.

comment:14 Changed 8 years ago by Christian Boos

Resolution: fixed
Status: newclosed

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.

Changed 8 years ago by Remy Blank

Attachment: nav-link1.png added

Changed 8 years ago by Remy Blank

Attachment: nav-link2.png added

Changed 8 years ago by Remy Blank

Attachment: nav-link3.png added

comment:15 Changed 8 years ago by Remy Blank

Resolution: fixed
Status: closedreopened

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.

comment:16 Changed 8 years ago by Christian Boos

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

  • trac/htdocs/css/ticket.css

    diff --git a/trac/htdocs/css/ticket.css b/trac/htdocs/css/ticket.css
    a b  
    8282}
    8383
    8484#propertyform .trac-nav {
    85  margin-top: .5em;
     85 margin-top: 2px;
    8686}
    8787#changelog { border: 1px outset #996; padding: 1em }
    8888.trac-shade { background-color: #eee }
  • trac/htdocs/css/trac.css

    diff --git a/trac/htdocs/css/trac.css b/trac/htdocs/css/trac.css
    a b  
    199199.trac-nav {
    200200 float: right;
    201201 font-size: 80%;
    202  margin-top: 1.5em;
     202 margin-top: 14px;
    203203}
    204204
    205205/* Alternate links */

comment:17 Changed 8 years ago by Christian Boos

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

Changed 8 years ago by Remy Blank

Experiment using icons for intra-page navigation.

comment:18 Changed 8 years ago by 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.

Changed 8 years ago by Remy Blank

Use min-height instead of height for #ctxtnav.

comment:19 Changed 8 years ago by Remy Blank

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

Changed 8 years ago by Christian Boos

Attachment: icon-navigation.png added

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

Changed 8 years ago by Christian Boos

Attachment: min-height.png added

Changed 8 years ago by Christian Boos

Attachment: min-height-wiki-ff-15pt.png added

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

Changed 8 years ago by Christian Boos

Attachment: margin-top-14px.png added

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

Changed 8 years ago by Christian Boos

Attachment: margin-top-wiki-ff-15px.png added

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

comment:20 Changed 8 years ago by Christian Boos

Ok, my turn :-)

With the icons, we still have the positioning issue:

ticket edit link with [attachment:8721-icon-navigation-r8891.patch]

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:

ticket edit link with [attachment:8721-ctxtnav-min-height-r8891.patch] wiki edit link with [attachment:8721-ctxtnav-min-height-r8891.patch], firefox 3.5 and min font size of 15pt

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

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

comment:21 in reply to:  20 ; Changed 8 years ago by 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 :-)

comment:22 in reply to:  21 Changed 8 years ago by Christian Boos

Resolution: fixed
Status: reopenedclosed

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 ;-)

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christian Boos.
The resolution will be deleted.
to The owner will be changed from Christian Boos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .

 
Note: See TracTickets for help on using tickets.