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 _______________________________________________ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
