[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
LYNX-DEV Comments on Lynx FAQ
From: |
Joe Kincaid |
Subject: |
LYNX-DEV Comments on Lynx FAQ |
Date: |
Sun, 1 Dec 1996 17:39:07 -0600 (CST) |
I've been reading Al Gilman's postings intently, but I'm not entirely sure
what I should do with them. It is clear that you (Al) have been thinking
about these issues much more than I have and I feel that I need to be
brought up to speed on them before I can do anything with them.
On Thu, 28 Nov 1996, Al Gilman wrote:
> As y'all work on what goes inside the new page tree, we need to
> be concurrently refining our plan for how it integrates into the
> operational configuration of the universe of Lynx help/support
> installations. Lots of ad-hoc teams have been ineffective
> because there was inadequate planning for what happens when they
> are "done."
This is a good example. I don't feel I can "refine our plan" without
more insight into what "our plan" is. I agree that this type of effort
will pay off tremendously, but I don't know how to carry out that effort.
Also, can you be more specific regarding "what happens when they are done"?
> I should probably try to work up a point paper on a sketch of the
> Lynx support installation after the rewrite.
Again, I would agree this would be helpful, but I feel this document
would be something beyond my capability to write.
> It takes planning. The HTML hyper-link is a one-way thing. The
> email archiver [equivalence class including at least Hypermail and
> MHonArc and Pipermail..] is an existence proof for the tooling to
> maintain bidirectionality over some class of links.
Huh? :-) I understood (to some degree) everything except "tooling" and
"over some class of links". Are you saying "we know it can be done"?
Is the <LINK ....> tag the means for doing this? I've always felt there
was more to that tag than I understood.
> But because the native medium of the Web is a directed graph, it takes
> tooling and planning to create something that is reliably consistent
> reading both ways. Actually, if we go into recognizing that
>
> Reference "how it works" documentation/services
> Tutorial "how to get going and gain skills" documentation/services
> Diagnostic "Now, what went wrong!" documentation/services
>
> are three concurrent views of a common corpus of knowledge (some
> facts just have to show up in multiple views) we should be OK.
I believe the FAQ Scott and I are working on goes into the third category.
I would like to work on the first two also (cf the original post where I
stepped forward into this), but since Scott offered to help with the FAQ,
that is where I started. Eventually, I hope to publish (available for
download, etc) a printed version of a Lynx manual. This would fit into
the first category definitely and likely will have parts in the second
category. I like having on-line references, but I also like having a hard
copy I can read in the car. (I'm not driving, btw :-)
> I think that we should be targeting to have different "layers"
> with a different tone and organization. The reference layer assumes
> [...description of the three layers omitted...]
> We need a three-view plan that explains how we are going to systematically
> link the document segments to build all three views.
If I understand you right, you are suggesting some sort of
meta-documentation that would add coherence to the documentation. I agree
this would be helpful. This is not something I had thought about though,
so if you _have_ been thinking about it, perhaps you could start on this.
I will think about this and if I have ideas, I will post them.
> > 4. The interactive manipulation of user options is a major topic
> > I don't see in your (top-level) list. -- linked to offline
> > manipulation of lynx.cfg and at compile time.
>
> This should probably be in the installation section with cross-references
> to it from areas that are affected by it.
>
> Well, in my view of how a trainee progresses up the skill ladder, they
> get to the o)ptions menu before they tackle lynx.cfg. So I would want
> the o)ptions menu given its own high-level visibility independent of
> installation.
Did I misunderstand you? I'm saying the manipulation of lynx.cfg would be
in the installation section. I agree the o)ptions menu will be
encountered first by a trainee, but I think it would usually be the
answer to a question, not the question needing an answer. I'm open to
suggestions.
> I have inserted a link to the new FAQ construction site in my page.
Thanks.
Joe
------
Joseph Kincaid | Mathematics is the alphabet with which God
address@hidden | has written the universe. -- Galileo
KSU - Mathematics Department | (except he said it in Italian, of course.)
;
; To UNSUBSCRIBE: Send a mail message to address@hidden
; with "unsubscribe lynx-dev" (without the
; quotation marks) on a line by itself.
;
- LYNX-DEV Comments on Lynx FAQ,
Joe Kincaid <=