views:

368

answers:

2

This is both a conceptual and how-to question:

In wiki formatting, or non WYSIWYG editor scenarios, you typically have a textarea for content entry and then an ancillary preview pane to show results, just like StackOverflow. This works fairly well, except with larger amounts of text, such as full page wikis, etc.

I have a concept that I'd like critical feedback/advice on: Envision a two pane layout, with the preview content on the left side, taking up ~ 2/3 of the page, and the textarea on the right side, taking up ~ 1/3 of the page. The textarea would float, to remain in view, even if the user scrolls the browser window. Furthermore, if the user scrolls the textarea content, supposing it has exceeded the textarea's frame size, the page would scroll so that the content presently showing in the textarea syncs/is parallel with the content showing in the browser window.

I'm imagining a wiki scenario, where going back and forth between markup and preview is frustrating. I'm curious what others think; is there anything out there like this? Any suggestions on how to attack this functionality (ideally using jquery)?

Thanks

A: 

Looks like a great idea! You might have a #preview and a #input, with the preview updated with a simple event:

document.getElementById('preview').addEventListener('change', update, false);
Delan Azabani
Yes. The part that's tricky in my mind is making the textarea scrolling sync with the preview content scrolling, so that the user is always previewing the same content as is being edited.
Roger Rogers
+1  A: 

Any markup language or simplified markup language like the wiki notation will differ from the output due to the formatting, so scrolling both textarea and formatted output by the same ammount of pixels or with some proportions will always loose sync.

Give them users two scrollbars and give up...

or

I've got an idea for You. It's based on the idea of not scrolling the preview at all, but generating it only from a currently edited part.

Finding out what is visible in the textarea was my first idea, but it won't be any more reliable than scrolling both views together.

What You can do is get the current cursor position in the textarea (can be done. has some browser issues) Then get some n characters before and after the current position rounded to full lines and generate preview from that. You can check for cursor position change every 1 or 2 seconds and upate preview if it changed.

n depends on the textarea size.

pros:

no sync problems, need to generate only a part of a larger text

cons:

updates only if user moves text cursor.

You could make it a feature... The textarea would be a dominant part of the page and the preview div would float by.

If You need more details or help just ask in comments.

naugtur
This does sound like what might be more reasonable. Maybe provide a way to 'click select' a region, bounded by a rendered tag, e.g. div, thus allowing the user to create an editor textarea that focuses on a smaller part of the content.
Roger Rogers
I thought about something like that, but it's content dependent again. Imagine some nasty user doing a paragraph with 3KB of text. It messes everything up. That's why I wrote about finding the text cursor in the textarea
naugtur