That seems to comprise a pretty good start on what I was asking for by starting with the user requirements. User requirements aren't UIs, if that is what you thought I was suggesting. Usually they don't coincide very well, because too many of the second are written by programmers without regard for the the first. Often they look suspiciously like data entry forms. I look forward to what you come up with. I think it's closer to what I want than you think. In particular, I'm not interested in helping anyone make individual tweaks to individual projects. I don't think you would come up with enough tweaks or enough tweakers. I think the biggest challenge is getting the users to think about their projects structurally rather than formatically (to make up a word, probably). Because their primary tool expresses projects almost entirely in terms of formatted elements, and there is no provision for a structural view. A better tool might look a lot like a simple outliner: title page <toc chapter 1 page 10 chapter 2 page 20 </toc <chapter> <chapter title> <p>........... <illus> <img> <caption> </illus> </chapter> They end up with a lot of those elements in there, but not clearly and consistentlyikdentified. On Fri, Feb 3, 2012 at 10:53 AM, Lee Passey <lee@novomail.net> wrote:
On Thu, February 2, 2012 3:37 pm, Keith J. Schultz wrote:
There a two kind of users. 1) the nerds here on the list with their pet technologies.
2) the average joe that wants to volunteer.
There are two kinds of people in the world: 1) Those who believe that there are two kinds of people; 2) Those who don't. ;-)
In fact, there are a number of different kinds of users on this list, there are even a number of different types of users in the first category.
Mr. Kretz has frequently criticized me for being too anxious to start coding and not taking the time the find out what the users' needs are. Ordinarily, I would have a great deal of sympathy for this criticism. In this case, however, the users I am targeting are not the ones he thinks they are.
I am committed to the goal of determining a single master format for PG works which is powerful enough to preserve and encode the structure of a document to the greatest extent currently possible, and from which all other desired formats can be derived. Thus, the targeted users for this goal are myself, Mr Adcock, Mr. Kretz and Mr. Hutchinson (Mr. Perathoner and the Bower Bird are excluded from this group of users as they have already made up their minds, so there is no need to consider their input).
Having looked carefully at TEI (and not so carefully at ReST) and considered available tools and familiarity, I have come to the tentative conclusion that properly constrained XHTML is the best choice (TEI is a close second). From this conclusion there are two tasks that follow: I need to develop the correct XHTML constraints, and I need to develop software tools that demonstrate and validate the correctness of those constraints.
The first and most important task is essentially a documentation task. The software development task is secondary, but is in support of the first. My strategy to achieve the primary goal is as follows:
Develop (and publish) guidelines (proposed rules) to govern the creation of PG texts in HTML. Create a few (several) sample texts which conform to the guidelines. Create a web service that will convert the sample text to a number of important consumer formats, including more than one HTTP version (HTML + external CSS), ePub and KF8. Examine the various file outputs and discover where the guidelines are insufficient or inadequate. Revise the guidelines. Lather, rinse, repeat.
I suppose I'll need to demonstrate that impoverished text can also be derived from the master file, just to keep Mr. Haines happy, but this gets low priority as impoverished text is simply no longer relevant to the world at large.
Mr. Kretz and Mr. Schultz are apparently focused on developing a tool that will allow interested end users to contribute minor edits to an instance of a master file. I'm willing and interested in developing the infrastructure to support this kind of a tool, but in this case the users I'm interested in supporting are not the proofreaders/contributors, but Mr. Kretz and Mr. Schultz themselves.
I'm not sure this rather personal statement of priorities is all that significant to the group here, but at least I hope I've made it clear to those people interested where I'm coming from. I'll try not to do this again.
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d