Edgewall Software
Modify

Opened 11 years ago

Closed 11 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: Branch:
Release Notes:
API Changes:
Internal 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 11 years ago.
Enhanced TracWiki editor, patch on r8859
nav-tweaks.patch (2.3 KB ) - added by Christian Boos 11 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 11 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 11 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 11 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 11 years ago.
TracWiki: enhanced wiki editor.
reworked-nav.patch (5.4 KB ) - added by Christian Boos 11 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 11 years ago.
nav-link2.png (5.4 KB ) - added by Remy Blank 11 years ago.
nav-link3.png (12.6 KB ) - added by Remy Blank 11 years ago.
8721-icon-navigation-r8891.patch (5.4 KB ) - added by Remy Blank 11 years ago.
Experiment using icons for intra-page navigation.
8721-ctxtnav-min-height-r8891.patch (1.5 KB ) - added by Remy Blank 11 years ago.
Use min-height instead of height for #ctxtnav.
icon-navigation.png (4.6 KB ) - added by Christian Boos 11 years ago.
ticket edit link with 8721-icon-navigation-r8891.patch
min-height.png (4.4 KB ) - added by Christian Boos 11 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 11 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 11 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 11 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 by psycho, 11 years ago

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 by Christian Boos, 11 years ago

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 by Remy Blank, 11 years ago

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

by Christian Boos, 11 years ago

Enhanced TracWiki editor, patch on r8859

comment:4 by Christian Boos, 11 years ago

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 by Remy Blank, 11 years ago

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

in reply to:  5 ; comment:6 by Christian Boos, 11 years ago

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

by Christian Boos, 11 years ago

Attachment: nav-tweaks.patch added

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

comment:7 by Christian Boos, 11 years ago

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

by Christian Boos, 11 years ago

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.

in reply to:  6 comment:8 by Christian Boos, 11 years ago

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

in reply to:  6 comment:9 by Remy Blank, 11 years ago

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 by Christian Boos, 11 years ago

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

by Christian Boos, 11 years ago

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

in reply to:  10 comment:11 by Christian Boos, 11 years ago

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.

by Christian Boos, 11 years ago

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 by Christian Boos, 11 years ago

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

by Christian Boos, 11 years ago

TracWiki: enhanced wiki editor.

by Christian Boos, 11 years ago

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 by Christian Boos, 11 years ago

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 by Christian Boos, 11 years ago

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.

by Remy Blank, 11 years ago

Attachment: nav-link1.png added

by Remy Blank, 11 years ago

Attachment: nav-link2.png added

by Remy Blank, 11 years ago

Attachment: nav-link3.png added

comment:15 by Remy Blank, 11 years ago

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 by Christian Boos, 11 years ago

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 by Christian Boos, 11 years ago

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

by Remy Blank, 11 years ago

Experiment using icons for intra-page navigation.

comment:18 by Remy Blank, 11 years ago

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.

by Remy Blank, 11 years ago

Use min-height instead of height for #ctxtnav.

comment:19 by Remy Blank, 11 years ago

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

by Christian Boos, 11 years ago

Attachment: icon-navigation.png added

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

by Christian Boos, 11 years ago

Attachment: min-height.png added

by Christian Boos, 11 years ago

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

by Christian Boos, 11 years ago

Attachment: margin-top-14px.png added

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

by Christian Boos, 11 years ago

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 by Christian Boos, 11 years ago

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

in reply to:  20 ; comment:21 by Remy Blank, 11 years ago

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

in reply to:  21 comment:22 by Christian Boos, 11 years ago

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. Next status will be 'reopened'.
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.