Introducing the future introduction of the AWE Editor 1.0. AWE stands for Advanced Word Editor and it’s something I’ve pieced together — in theoretical form — out of my experiences with MyWiki and TinyMCE. There’s also a little bit of vi energy thrown in for good mix.

Here is what I need

I need an editor that tags each individual word OR series of words with metadata, yet looks and edits like regular text. Each word would have metadata attached to it. In theory this is possible by using HTML, as follows:

This type of construct would be used in display. While the text is highlighting a certain word — such as when that word is clicked on, the metadata can be edited in a side window.

Then it could be displayed like regular text but we would also have word-level control.

If we are using textarea, the jquery caret plugin will give us what we need. Otherwise we can use javascript to edit each individual element. This could be displayed below a textarea. Then we would click on each word and issue commands via javascript.

How will the data be stored?

I came up with quite a few methods, but JSON is definitely one idea. So, it would be stored in an array. But it could also be stored in a custom text format designed to be read left to right (similar to how MyWiki processes some tags). This is a very fast way of processing the text, so it would be ideal as the amount of text we need to process increases.

But the issue with “how will the data be stored” is conevrting back and forth between formats. Is it possible, in fact, to store the text metadata along with the text, in a form of markup?

For:1 example:2, if:3 we:4 used:5 colons:6 to:7 mark:8 each:9 word:10, then:11, we:4 might:12 put:13 a:14 dictionary:15 id:16 after:17 the:18 word:10.

Also1 given2 that3 numbers4 and5 words6 do7 not8 mix9, when10 a11 word12 contains13 numbers4 it14 might15 be16 considered17 a18 key19.

The advantage of the first style of markup is we can directly annotate part of speech into the text.

Here’s(cont) another(det) example(n) of(conj) a(art) possible(adj) style(n) of(conj) pos(n) tagging(v).

Storing the data apart

Also, nothing says that the data has to be stored together. There could be a simple text, and then beside it, a list of pos tags and dictionary IDs. such as n:151 for noun, dict. id 151.

How will it be edited?

Since the metadata will be modified manually, but with editor support, it will be easy to keep track of the metadata. One idea is parallel texts. In parallel texts as described above, you can use a textarea where changes are replicated into a data array. In another form, you could use two textareas where changes are replicated between each. So an insert event for example, will be captured by one and propagated into the other. Then the user could edit only the metadata tags in the metadata window (to keep things simple).

Typical Solutions

Textbox & Textarea

A two-window solution would be a textarea and a text input. When a word is identified in the textarea by use of caret position, the metadata for that word is shown and editable in the text input. On paste, we can easily interrupt the event and process the text before we insert it, so that we can update the back-end array of data necessary to store all the metadata information.

This would be done using jquery’s caret plugin (or just selectionStart) to determine the position within the text. This could then be compared to the “start position” of each back-end data array element to find out which array element we are “in”.

var cursorPos= $("#mtxt").caret();

Pasting text, on the other hand, will jumble things up. We need to process all the inserted text. This is not a problem; we know where we are in the text; If we are between two spaces we know we’re on a certain array element, otherwise we’re on a different one (one which contains a word). We just use code similar to the following (below) but instead of UPPERCASING it, we pass it through a tagger and update the array to match the text, as if it was typed character by character.

Double Textarea

Double textarea solutions are of two types, and may include a text input to aid in metadata editing. But the essential feature here is you can edit the tags in-line, which is more convenient in the sense that you can focus on the editing experience and move freely around in the textarea. This uses technology similar to above. Cursor movement and inserts in one are replicated between the two using the same handler; with the difference that cursor key motions are replicated in a special way; when moving in the text box moving across a space will cause the cursor (caret) in the second box to skip over the metadata and appear to “follow” onto the word; while moving within the metadata of the second box will stop edits going to the first window and allow the user to edit the metadata in the second window only.

Textarea + Inline Editor

This is an interesting solution. There will be a textarea, and the backend data array will be displayed also as normal text, but wrapped in HTML such as discussed above, ex:

So now, you can click on the word to edit it’s metadata.

This has certain advantages; working with a system like this will enable us to allow the user to do interesting things such as clicking on words they don’t understand. So this system could be used in a display format. But in an editor, having the user click on various words represents a tradeoff. First they do not need to learn any special markup format, but secondly they are required to click on words. This may again be solved simply by adding a control key such as control-dot, which opens a modal for example, for metadata editing.

One downside of this solution is that all the metadata is not displayed on the screen so it can be difficult to find an error just by looking.

Multiple Solutions in Tabs

In the end it seems as if having all of the above may serve people better than just having one. But if you could only have one, the easiest is going to be the first one probably, especially if we add some kind of command to move forward and backward by word. The others can be added in tabs later.

Step one, create and maintain a back-end data structure as the user transparently edits text in a textarea. Step two, allow edit access to that data in a text input based on context.. Step three, link two textareas… This could work!

By Serena

Leave a Reply

Your email address will not be published. Required fields are marked *