
Hi BB, It is hard to give a good response to this post. Your points are valid enough, yet only at a narrow perspective of things. Naturally, a system is only as good as the experience of the developer(s) and designer(s) of it. Yet, you just put your foot in your own mouth, because according to you, your experience is of not use to your own system! (see your own comment below). Nobody, said that OO or MS was a vital or necessary tool in the workflow, just what they use. Whether, we agree with their choice or not. The complexity of software or the workflow is not really important to the user. As you well mention it is more important that it is easy for the user to use. As a proof of concept, I give you the all so famous google search engine. The user interface is simple enough. You just enter a search string and out comes the result. Yet, there are database, heuristics, cookies, spiders and god knows what not working 24/7 in the background so that you get what you want, and you need not know anything about these things or care how they do it. It is quite complex. So it boils all down to give the user a properly simple interface to the system. Finally, do we have to always use d.p as an example. I think we can agree that d.p has it flaws. It is their implementation and interaction with the users which is the problem. The suggestions made here are doing down different routes. They may use simpler tools, but in a different way. You have a text format, a workflow, editors, spellchecker, etc. But you do not use them like d.p. So should I say that you should not use a editor, a file format, a spellchecker. No way. use them by all means. Yes, you can use all you like or leave out all you dislike. D.P. is not the kid to beat. True, there are lessons to learn from d.p., but it is not how to design things using the tools they use. And, more… regards Keith. Am 16.11.2011 um 21:43 schrieb Bowerbird@aol.com:
given all of the recent topic-shattering, it's only natural to feel a little scattered.
so let's take stock, and regroup.
first of all, it's _cool_ that people feel free to share our individual e-book workflows.
other individuals here might learn from it.
and more importantly, we might come to learn something that could be of use to us in building a system for collaborative work.
it seems to me that a collaborative system is more in tune with aims of this listserve...
and if your workflow depends in a vital way on your own individual experience or talent, it's not gonna be of use to that, not really...
likewise, if it depends on a software program (such as ms-word or open-office) which has grown to be a gnarly complex monster, then odds are people aren't gonna want to use it. fine for your use, sure, just not for our use...
also, hand-in-glove here, if the app requires a good deal of hand-holding, that's not good.
what we want, then, is simple software that takes care of a simple workflow, and which can run either offline or online, invoking a system for collaborative e-book digitization.
in this vein, we find distributed proofreaders. they have such a system, and such software... and, for the most part, although they will say that they are not completely satisfied with it and have lots of features they'd like to add, they often turn down coders who volunteer... (when those coders will not be subservient.) so my impression is d.p. is happy with itself. and the same can be said of the p.g. machine. i don't get a feeling they want any help either. they don't want you to meddle with their stuff.
in a way, that's pretty liberating, since it means we don't have to support any lingering baggage. we are free to design a system any way we like...
i've built the engine of such a system. if people would like me to put it up again, for evaluation, i could do that. (it was the old "sitka" project.)
roger frank also coded the engine for a system. he has also taken his project down, but i bet if enough people expressed interest in seeing it, he'd also remount it, so you could evaluate it...
***
all these systems are pretty "standard", in that the interface has a text-field and shows a scan. if a review of the scan reveals the text is wrong, you edit the text. it's all very straightforward...
other interfaces have been suggested as well.
i made one where each text-line is displayed next to a checkbox that should be checked if the line contains any errors, so that that line will later be corrected by the administrators.
i made another one where questionable lines get shown in various forms, and the person is asked to indicate the one which is correct. (that's for when multiple files get compared.)
we also saw an interface from edward betts on this list recently, where lines are shown under the relevant slice from the scan, and the person clicks any incorrect word to fix it.
so the interface can vary as well as the tool...
***
it's easy to code an e-book digitization system.
since the d.p. code has grown into a monster, people familiar with that code might laugh at such an assertion. but i make it with certainty:
it's easy to code an e-book digitization system.
i've already done my autumn project this year, so my plan was to wait until spring to do this, but if people want to go to work on it _now_, just let me know, and we can start a project to collaboratively code such a digitization system as an open-source project. since, as i just said, i've already done this, i could serve as a guide.
but i'm not going to just hand over my code, so if you want it to be open-source, you'll have to do the vast majority of the coding of it yourself.
and that's good, because it means that you can make the choice of the language by yourselves.
let me know.
if nobody's interested in tackling such a project, i'll do another how-to series, on digitizing tools. in fact, i might do that either way. yes, yes i will.
so, by all means, if you want to share aspects of your personal e-book digitization workflow, do! most _especially_ if they might have relevance to a _collaborative_system_ for digitizing e-books...
but if your individual workflow is unique to you, you must recognize that it's not of any use to us.
-bowerbird _______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d