Though I've run many books through DP's proofing and formatting workflow, I always thought it would be easier and more fun if the computer gave feedback about what it thought of the page as it was being proofed. To test this out, I have written a multi-pane editor that may be useful for etext production. I loaded a book into the demo version of the program at http://etext.ws/ppe.php and I'm interested to know if it works for different users with different browsers. It uses several HTML5 pieces that I think are safe. Open source, MIT license, as is all my software tools for etext production. The left pane is a text edit area for a page. Center pane shows the results of analysis for that page. Top pane is a clickable image of the page. Various status information is lower right. Still to do: spelling check, common scanno flags and many more regex checks. Right now it includes spaced or crunched punctuation, poetry detection, end-of-line hyphens (which may be resolved with the DHYP button) and a few others. I also want to use a magnifier jquery plugin on the image to dynamically enlarge the area under the mouse instead of having to open another window. I will solo post-process a few books using it. If I can make it work well enough, I'll add the page queue code (i.e. "next unproofed page"), instead of how it is now, where you select the page to proof or it gives you a random page. As you proof, the status area displays how many times the page has been proofed, as this is all tracked along with all earlier revisions in the database. There is no login required and I'd appreciate if you would take a look at it. Feedback welcomed to the email shown in the application. I'll summarize (if there is any interest) back to this thread. --Roger
Thanks to those that are looking at the editor. There seems to be some interest so here are the first reports and my comments. 1. "requires a huge screen to be feasible." Yes, it does. I played around with a two-pane version, just the edit panel and the analysis panel. Those are the important pieces. Then I added the image panel to the right. Having the image right there allows the user to quickly scan the original to see if there are missing paragraph breaks, or poetry that wasn't indented. I found that for every page I edited, I was looking at the page image, so I felt it had to be there. The alternative is a pop-up, on demand. Perhaps it makes sense to have a two-panel version with a pop-up for the image for those that don't have large screens. My thought was that most people had larger monitors these days and that the added functionality of a third pane, holding the image, would be worth it. 2. "the image to the right is very small and ... not useful" I tried one version of this software using a image pane the same size as the edit panes. That made the footprint even larger, too large for a laptop screen of 1440x900 pixels. The way it is now, with the smaller image, users click on it to examine fine detail. I'd like to use a magnifying mouseover for this eventually to avoid opening a separate window. 3. "page numbers not synced to image." This is a creature comfort issue and I'm glad a user brought it up. For this to be useful to the widest user base, they should not have to know what a PNG file is and certainly should not have to deal with a PNG number representing a different physical page number. I have reloaded the database to resolve that inconsistency. 4. "it doesn't work in IE6." No surprise there. The application is built with HTML5. There are probably techniques I could use to make this work with older browsers, but that would be far down the road after this editor proves its worth. 5. "text is truncated on my screen." The application is supposed to be able to resize. If your monitor is too small for the application as it is presented, try reducing the geometry. On the Mac, that's with command + minus keys. Not sure on Windows. That may make the editor too small to be unusable. If this is reported many times, then perhaps I should revisit the two pane version of the editor. 6. "no way to save the current page without asking for the next page" Good point. It's not clear how to do that. One way is to use the GOTO button to go to a new page. That saves the one being edited. Another way is to use the exit button. That saves it also. Still, this is confusing. Seems there should be several buttons to make this more intuitive. 7. feature request: feedback to appear in real time as you type That would be ideal. That won't happen for several reasons. First, I am an amateur programmer at best and event-driven programming in a browser is beyond me. My head is already spinning keeping track of all the traffic between the client and server sides and the backing database at the page level for this application. Second, I've learned a lot about real world limitations of servers. I believe that what you're asking for could only happen in a standalone application on the user's machine. This same functionality in a standalone package might be very useful, but we're back to the old problem of the user having to install Python or Ruby and then keeping up with revisions of the program, etc. An always up-to-date online version, even if limited in real-time response, seems a better solution. Thanks again to everyone who has sent me reports on this. --Roger
participants (2)
-
Joshua Hutchinson -
Roger Frank