Re: more on TABLEs

to follow up on what Gregg Vanderheiden said:

> Woa
> This is good stuff but..
> 
>  How much of this can be either
>  - be done automatically (no author intervention needed)
>  - or bbe done by the author by making a simple gesture  or dealing with it 
> in very simple english terms.
> 

Yes! Talk about things that have been on my mind but I haven't
written about them...

This is going to be a quickie because I only have a limited
handle on the problem.  We need eventually to work seriously with
the tool people in the tool guidelines group.  But since one of
the things driving me is a sense that this is the kind of thing
that an author can relate to and a tool can make as easy as the
rest of the table composition, let me take a brief run at the
question.

> I am concerned that people laying out tables will do it WYSIWYG and won't 
> even know what a spanning title is (even if they use one) much less be able 
> to tell the program whether the table is row or column dominant.
> 
> Can you help me by saying what this would look like to an author?
> 
> What would they be asked to tell the web author tool about the table in 
> order to get the tool to code the table html correctly? (assuming the best 
> case with regard to html being able to code the info)
> 

Can the author dig it?

I absolutely agree with you that we want the attribute and
variable definitions to be concepts that authors could address
easily in conversation.

If I were sitting down with an author looking at her table on the
screen, I might point to a TH cell and say, (regarding is-a
relationships):

	"This cell tells us something about some of the other 
	cells -- which other cells."

That question is exactly the relationship that I want the
client software to know.

Most of the time, the author would laugh at me because it was 
obvious.  The data-descriptive information is either at the head
or on the first-read [default left] margin and in that order
precedes all data cells.  And it governs everything that comes
after it.  The expense account that Dave drew up is an exception,
but not that unusual -- there is one data description for all
the data cells in the interior of the table, so it is lodged
in some global site like cell(1,A) or title or footnote.

Can the author dig it [part 2]?

The other kind of relationship has to do with keys.  In this
case the canonical author query is something like:

	"What other information do I need to have, along
	with this fact, so that we don't wind up comparing
	apples and oranges."

I think that most table authors would give you an appropriate
response to this question the first time you asked it.  Maybe
I am overly optimistic.  But in the case of tables where 
there are both multiple columns dedicated to case-selector
keys and also multiple columns devoted to different "output"
characteristics of the case so selected, the author know which
are which.  Each output needs to be prefaced by all inputs
but outputs can safely be read in isolation from other outputs.

Can the tools automate it?

In both cases, what we have is a directed relationship between
a cell and a set of cells.  Table authoring is basically a
subset of the I/O dialog moves used in spreadsheets.  What a
GUI based authoring tools would do to capture relationships
like these is a hybrid of 

	- what you do in HTML authoring to create an internal
	hyperlink, e.g.
		-- mark target
		-- mark source
			-- select target

	- set-building moves used in spreadsheet manipulation
		-- rubber-banding to designate contiguous rectangles
		-- shift-click to accumulate a set that is
		composed of multiple mouse-points.

Default rules can be exploited to expedite authoring as well
as to economize tags in the HTML.

If an organization wants to support a markup discipline above and
beyond the minimums of the HTML specification (or even if it
wants to check that) the authoring system can use scripting to
query the author with visual highlighting to indicate the current
answer to certain questions and textual prompting as to the
question at hand.  [Like the two questions above] All you need to
cue a cell-to-cellgroup relationship is two separate styles of
transient highlighting for the source cell and target cell set.
The way you check this kind of content semantics is some kind of
a semi-automatic checking drill -- does this answer match this
question?  This is a lot like the dialog that is precipitated
when spelling or grammar detects a possible problem.

Here the author would enter the manual designation dialog if
the default rules don't link the cells right.

The system might just kick into "manual designate" mode in hard
cases such as where a TH shows up in the middle of the table
after some TD's have been encountered.  Those are cases that
don't match any defaulting rules.

Those are some of the notions that have been rattling around in
my head.  These brainstorms aren't designs for production tools.
But they are some sketches that encourage me to think the
functions are reasonable to automate.

-- Al

Received on Thursday, 2 October 1997 11:06:25 UTC