Third-party or "out of the box" plugins [was "re:

[mcarr at allette.com.au]

Eric Dunn wrote:

> Now what exactly is the difference between "hunt and peck" and "drill".

Drilling through a graphical user interface would involve pointing at hot
spots to get to the subsystem of interest, then working from a list of
commonly required process - Servicing, Repair Procedures, etc. Hunt and
peck would involve someone typing into a search form on a keyboard. Is
that really your question, or are you asking what the advantages are of
each?

> And how is a toughened and oil covered touch-screen and more elegant than
> a toughened keyboard? It's poor form to use derogatory terminology for one
> option we don't support and positive terminology for the one we do. The
> statements also unveil a certain snobbery of IT superiority by denigrating
> those that work in other fields. Denigrate anything linked to the awful
> old hands-on industry and try to enlighten it with beautiful IT derived
> terms and symbology.

My apologies if it sounds like snobbery - it was not intended to. When I
was young I spent 7 years on an assembly line (http://www.travelaire.com/)
and a year digging ditches (sorry, no URL). When I leave IT, my next
career will be much more hands-on - I like factories and equipment. I
accept that it may have sounded like snobbery, but I don't think it was,
really.

As for whether a touch-screen is more elegant than a toughened keyboard,
frankly, you're missing the point. I don't know or care what the devices
will look like in ten years, but the discussion isn't predicated on that.
It's the data and the ways of accessing it efficiently that we're talking
about.

> Drop the prejudice against indices as a hardcopy only issue and recognise
> that index information is useful metadata, regardless of how it is
> ultimately searched and presented.

I don't think you've been reading this discussion properly and given your
tone, I'm not inclined to explain it again. I haven't been advocating the
abolition of indexes, I have been noting that an index is most useful when
it has been created based on the view of the data that the user will see.
As the trends toward syndication and purpose-driven republishing of
components increases, conventional indexing tools begin to show a
weakness, as there is no "final" view of a document. How do you decide
whether to direct a user to an occurrence of a term in one fragment or
another when you don't know which fragments may ultimately be combined, or
whether this fragment will be combined with an as yet unknown and
altogether different publication? Obviously, you cannot know how best to
index a publication that does not yet exist.

Alternate ways of collecting and presenting metadata are precisely what I
was arguing is necessary. My point was that metadata organisation and
presentation has to be carried out *after* the publication has been
assembled. If you want to pull those derived publications into FrameMaker
and index them with an improved version of what FrameMaker already offers,
well, knock yourself out. Most organisations will be looking to replace
you with software though, and Adobe will presumably be only too keen to
facilitate them.


Marcus Carr