That seems to comprise a pretty good start on what I was asking for bystarting 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.