lynx-dev
[Top][All Lists]
Advanced

[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.
;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]