RE: svg and events

At 02:54 AM 2002-03-13 , you wrote:
>> >Issues:
>> >	How to present the navigation method to the listner?
>
>I know what to say, its how to say it / present it to 
>someone opening the diagram. Its the equivalent of having instructions
>to open a parcel inside the parcel !
>

OK, I am perhaps almost caught up to where you were when you started the thread.  Or as I now see it you are ready to try some prototypes on real users and for this you need real players that support _something_ in order for you to try _anything_.

For which Charles has better information than I have.

I still don't think that someone else can help you much without guinea pig drawings to talk about.  I have trouble coming up with generic methods that presume a content model as flat as that of a still life of a bowl of fruit.  But I am sure there are many drawings that fit that model.

My head is into the "virtual tumor board" scenario where the critical evidence is a slight cloud that appears at the margins of a particular small organ like the hypothalmus in one composite image; a cloud that isn't there in most similarly-composed images from comparable patients.

vocabulary: a 'tumor board' is a professional peer review of patient evidence prior to actual treatment in cancer cases; a 'virtual tumor board' is such a consultation taken at a distance as computer supported collaborative work. 

Al

>Hi Al.
>> >My principles to date are:
>> >
>> >1. document order to match 'described' order,
>> >i.e. logical progression from overview down to detail.
>> 
>> In general this cannot be done.  You have to use the 
>> define/use cycle in SVG to first provide text in some 
>> plausible narrative order and then reference the text in the 
>> encoded drawing structure which is not a linear order but a 
>> hierarchical scene graph.  It is not practical to try to 
>> force the 'g' drawing group hierarchy into a narrative order. 
>>  The prior declaration of the text in narrative order can be 

>> in an embedded foreign object in XHTML Basic, for example.
>
>OK, taking my defs as being 'data' or hash defines, substitute
>use instead of actuals.
>
>I think it is practical. I hope you can't prove me wrong.
>The drawing order is only relevant in terms of what overlays
>what, and (I think) that can be sorted.
>
>
>
>> 
>> >2. Each document entity to be wrapped in a g element,
>> >   with min of desc and otionally both title and desc children.
>> 
>> That is to say each distinct scene object of enough 
>> conceptual significance to be mentioned in the description.
>> 
>> Catch:  The 'g' drawing groups are part of the strict XML 
>> hierarchy.  The conceptual objects one wishes to describe 
>> form a general Venn diagram -- not a strict hierarchy.  There 
>> are intersecting groups in the display that have both common 
>> and distinguished sub-elements in them.  So some of the 
>> notional elements may have to be documented as collections of 
>> drawing groups, presumably via RDF in the 'meta' section.
>
>Agreed, re-use will limit that. Simplistically any 'object'
>will be within a group, though its children maybe uses of 
>def'd content.
>
>
>> The first navigation assistance to think about is 
>> hierarchical, not linear.  
>> 
>> It is presumed that you can create a contents tree for the 
>> display without too much mental sweat.  A possible 
>> orientation technique is a one-level contents summary list in 
>> the 'desc' element or in SVG attached to the 'g' structure 
>> containing articulable substructure.  In any case, the way 
>> you present the navigation hierarchy is by some emulation or 
>> approximation of the DAISY book Table of Navigation and 
>> associated navigation techniques.
>
>Since I never 'describe' a figure in this way, I'd rather approach
>it by providing a 'summary' / precis initially (This diagram shows... )
>then go into the diagram. The missing elements will be the reader
>commentary which says something like 'which is adjacent to the xxx'.
>
>I want to avoid a 'special' nav table if possible, since it fits
>unnaturally into a visual diagram.
>
>
>> 
>> A linear tour through the scene takes more mental effort, but 
>> one has to think through the tour order before one can 
>> consider tabbing through [the tour of] the scene. 
>
>You got it. It takes practice to audio describe a diagram.
>
>
> This 
>> depends on the author's understanding of the story that the 
>> scene has to tell.  It is not recognizable in the XML 
>> hierarchy without additional help from some human.  

>
>(or the diagram author ;-)
>
>
>> >Issues:
>> >	How to present the navigation method to the listner?
>
>I know what to say, its how to say it / present it to 
>someone opening the diagram. Its the equivalent of having instructions
>to open a parcel inside the parcel !
>
>
>Regards DaveP
>(Also a volunteer reader for 5 years).
>
>
>- 
>
>NOTICE: The information contained in this email and any attachments is 
>confidential and may be legally privileged. If you are not the 
>intended recipient you are hereby notified that you must not use, 
>disclose, distribute, copy, print or rely on this email's content. If 
>you are not the intended recipient, please notify the sender 
>immediately and then delete the email and any attachments from your 
>system.
>
>RNIB has made strenuous efforts to ensure that emails and any 
>attachments generated by its staff are free from viruses. However, it 
>cannot accept any responsibility for any viruses which are 
>transmitted. We therefore recommend you scan all attachments.
>
>Please note that the statements and views expressed in this email 
>and any attachments are those of the author and do not necessarily 
>represent those of RNIB.
>
>RNIB Registered Charity Number: 226227
>
>Website: http://www.rnib.org.uk 
>
>14th June 2002 is RNIB Look Loud Day - visit http://www.lookloud.org.uk to
>find out all about it.
>

Received on Wednesday, 13 March 2002 09:13:22 UTC