fweeb / wordpacer Goto Github PK

The current usage workflow requires that a person click the Analyze Text button to see any updates in the velocity graph. It would be much nicer if, like the Markdown parser, the graph automatically updates as the text is being written. Achieving this, however, might require some major work.

A bit of a performance boost can be had by changing how the text is collected/saved/parsed. There's currently no caching... so the text is ingested and processed in whole each time. Treating the text as a stream should yield better results on the data collection and calculation side of things.

The other slowdown, however, might be in jqPlot itself. I'm not sure I can make that any faster on my own... and I'm not sure that there are any other graphing/plotting libraries in Javascript that provide better performance. Suggestions welcome.

The velocity graph assumes paragraphs are in header or paragraph tags. Lists are currently not accounted for properly.

I think you have enough screen real estate, and they're interesting to see.

Stats rounded to an integer are enough. So Minimum reader velocity: 114 please, not Minimum reader velocity: 114.58333333333333

If there are reasonable benchmarks to show, that would be useful. I.e. average word length here is interesting, but it would be more relevant if I could compare it to a benchmark like "Mary Had a Little Lamb" or the script to "Killdozer 3: Now It's Personal"

Currently, Word Pacer only supports Markdown. However, it should be expected that people may paste in text from other documents. This text will not be in Markdown. The biggest complication here is that Markdown assumes a new paragraph after two carriage returns whereas most word processing software uses only one carriage return and then uses styles for spacing. That means that paragraphs would not be properly recognized in pasted text.

There are two possible solutions:

1. Automatically convert plain text to simple Markdown when it's pasted by adding those additional carriage returns.
2. Have a plain text mode that recognizes a single carriage return as being a new paragraph.

I'm not sure which is the best solution. The first seems more elegant, but I'm not sure if it's possible to pre-process pasted text... and I'm if it would be disorienting to a user to see the result being something slightly different than what they copied. The second is certainly easier to do, but it requires an additional toggle in the UI and I'd like to keep those to a minimum.

Since it is rendered much larger in the Markdown output, it's size suggests that you should paste text where you can't actually do such a thing

If there are hyperlinks in the text (generated by Markdown), the highlighter doesn't account for the HTML mark-up around the highlighted portion of text. This needs to be fixed.

Abbreviations tend to mess up velocity calculations by prematurely marking a sentence as ending. I can't cover all abbreviations, but it'd probably be a good idea to address common ones like the following:

• e.g.
• i.e.
• Dr.
• etc.
• Mr.
• Mrs.
• Ms.
• St.
• vs.
• v.

The difficulty is that I'm currently using a very simple regex to separate sentences. Building exceptions like this could complicate that regex pretty heavily.

Consider only showing labels when zoomed in and autohiding otherwise.

Alternatively, it may be nice to have a mechanism to show a small floating window of text with the relevant sentence or paragraph fully visible while your hovering over relevant sections of the graph. This may require some more direct hacking on jqPlot to work properly, though.

Considering the fact that currently the graph doesn't update until you click the Analyze Text button it should be larger and/or in a more expected location.

Processing large amounts of text is time-consuming. If performance can't be improved it would be wise to let the user know that something is actually happening. Since this is all pure client-side Javascript, that might be a little tough (there's no AJAX asynchronous stuff going on). Javascript on the page would just need to load smarter... and perhaps cache locally.