RE: RDIG Call for Presenters

Thanks for the excellent comments. I'll respond in-line (<mth>) to the
summary, but start with one item in the detail:

> I am bothered that the current draft is plain text and not hypertext.

There is an HTML version of the call. Formatting was being checked with
Wendy. Your comments, along  with others received will be incorporated into
the HTML version, and the URL will be sent to the list within the next day.


> <summary>
> The timing here couldn't be worse.  This activity is in competition with
> the CSUN conference and comes in the teeth of people's engagement
> with that
> conference.  How can we ask for submissions at a time when 2/3 of
> the people
> we are soliciting are wrapped around that competing axle?

I did not see the audience at CSUN as our targetted presenters, as our
charter is to reach out
to the greater web research community. Obviously, I want CSUN people to
participate, but not necessarily as presenters in this instance.  I see the
greater competing event as CHI 2003, which occurs in early April.
March-April is a problem, but we need to get going.

> This Call for Participation should follow more closely the best current
> practices for workshop and event ads.  It should have

<mth> Comments helpful... this was a draft to solicit such advice. </mth>

> - a "who should participate" statement that names names of specialties
> - more concrete guidance on how to present and format the
> materials that are
> initially and will ultimately be asked of the participant.  What is asked
> for should be friendlier to the work habits of academics and gather
> references and not just summaries.  [Also if you are going to
> record, which
> I recommend, that participants are required to consent to this.]

<mth> Recording, and even real-time audio stream for those not able to
connect via telephone is planned. Consent will be required for recording.
Presenters and participants will have to fill out a registration form
acknowledging IPR and consent for recording. </mth>

> The event should be pitched as an interdisciplinary conversation.  Not an
> exploration of a recognizable atomic domain.  Make it clear that you want
> people to orient others to their home domain as well as report
> deep research
> findings as well as reflect on others' input in the light of their
> background and expertise.
Good comment.

> The topic of this event should be located for the CfP reader by the
> intersection (logical AND) of the following more recognizable conditions:
> + Deliverable-oriented Knowledge Work[1]
> + By dispersed teams[2]
> + Including PWDs[3]
Good idea.

> For the general issues that come up in this domain, my latest survey [very
> rough document] is at
> You should think about including a bullet-list summary of ideas like the
> ones in that reference in a "some of the issues in this domain
> that you may
> be able to shed light on include:..." section of the CfP.
<mth> Will look at it </mth>

> The entire lifecycle process of the event should be better laid
> out at least
> in terms of how the real-time discussions will be reported in public and
> what control the participants have over that information release.

<mth>Agreed. Lifecycle needs expansion in the call and also on the RDIG web
pages </mth>

> </summary>

> [Caveat:  I haven't reviewed the templates.  Some of what I am asking for
> in the CfP can be handled by brief summaries with links for details to the
> templates.]
> The CfP document: this document [call for participation] should
> follow more
> closely the genre as practiced by people who organize and advertise
> meetings that draw an ad-hoc collection of participants.  [as opposed
> to meetings of standing bodies.]  Compare and contrast this with
> one email CFP that is contributed by each individual in the
> planning group.
> The event: frame this as an interdisciplinary conversation.  You
> are not trying
> to establish the topic of this conversation as the theme of a
> continuing series
> of meetings.  You are trying to invite participation in a
> conversation which
> falls within the loose topic and goals of the RDIG.  This
> conversation is not
> to continue the advancement of knowledge in an established or
> proposed domain,
> but rather to cross-inform workers in domains that touch this
> topic.  Out of
> the process a clearer research roadmap for "the accessibility domain" may
> emerge
> but it is not presumed
> Not just the ACM, the commercial event promoters.
> "who should attend"
> "you will learn"
> ..etc.
> I don't see from this draft how the researcher is told what is in this
> opportunity for them.  I see the rationale in terms of the glowing
> greater good, but where is the answer to "What's in it for me?" from
> the perspective of each researcher reading this?
> I see two attractions:
> - visibility -- gain recognition; credit for publishing (standard
>    inducement for academic publishing, weak position for RDIG in
> this regard)
> - learning -- each researcher is briefed with a focused executive briefing
>    by others doing work that may bear on their own knowledge accumulation,
>    either bringing things that they can reuse or warning them not to seek
>    recognition for what others already have laid claim to.
> While it is hard to demonstrate academic researchers acting on the latter
> incentive as opposed to the former, it is probably the best carrot that
> this group (as a magnet-wannabe) can offer.
>  From my personal experience I can testify that it does work for those who
> will suspend disbelief and invest in the process.  I always come away
> invigorated from a brush with people doing real things in
> neighbor domains.
> But this does cast a doubt on whether you want to go for a pure-researcher
> population.  It could be more constructive to call for participation by
> researchers and practitioners.  The objective is to improve the statement
> of the "interesting research questions" in this area.  This is
> the standard
> mission of the workshop that NSF runs prior to committing a line
> of funding
> to a topic.
> I am bothered that the current draft is plain text and not
> hypertext, and that
> you didn't encourage hypertext in the response.
> The domains and some exemplars that I would invite to cast light on this
> topic include:
> - organizational behavior and sociology Lee Sproull, Lipnack and Stamps
> - organization and workflow and information architecture design
> Nick Ragouzis
> - operations research Barrett Caldwell, Wolf Kohn, Anil Nerode
> - groupware infrastructure Geoffrey Fox
> - psychology, esp. EdPsych
> - cognitive science
> - software engineering
> - human-computer interaction
> - assistive technology
> - disability studies
> It is not clear from this writeup if there is only one class of
> participants:
> only those invited to speak are listening (in real time) or is it more
> like a town meeting where there is a section with questions from the floor
> and a broadcast channel of the telcon channel in real time to
> listeners who
> can only assert stuff through text messages.
> I believe you have a process template that talks about the life after the
> synchronous-time rendezvous to get to a static patch-of-web content.
> individual researcher who is solicited
> to do the work of filing a brief, here and possibly participating in the
> telephone conversation
> >Al,
> >
> >Thanks for joining the call on short notice. Your comments were
> helpful, and
> >a reminder of where RDIG needs to go. We have, after alot of
> deliberation,
> >settled on a less agressive, narrow model for the first topic. However,
> >anything you can contribute toward the use cases or call would be most
> >welcome.
> >
> >Attached is the latest draft of the call, reflecting comments from the
> >planning group.
> >
> >Looking forward to your input.
> >
> >regards,
> >mark
> >Call for Submissions
> >
> >The W3C WAI Research and Development Interest Group announces a call for
> >submissions for our first International Teleconference on Document
> >Collaboration
> This makes it sound as though the topic of the [c.f. ISSN] whole
> series of
> events
> is Document Collaboration[4].
> Title the event "Tele-Workshop on Universal Access in Team Work"
> then after
> naming the event, say "first in a series of research-focusing
> events in the
> area of accessibility and Web-related technologies."
> >Introduction
> >
> >The web is bringing together inviduals and enabling them to
> collaborate in
> >new
> >and innovative ways. Today, diverse communities of people can come
> >together in
> >virtual spaces for meetings and working sessions. This is particularly
> >important
> >as travel to face to face meetings can be difficult for budgetary or
> >security reasons.
> >
> >Examples of such communities include standards development, engineering,
> >knowledge management, software/content development,
> accessibility, scientific
> >research, government/international rules and regulations, and education.
> >Diverse, international groups currently use a variety of tools, such as
> >instant
> >messaging, IRC, shared desktops, and teleconferencing for real time
> >interaction,
> >as well as email, mailing lists, weblogs and proprietary format
> documents for
> >asynchronous interaction.
> >
> >Collaboration, for example, on a design specification, is typically
> >accomplished
> >by using several of the aforementioned technologies, with little real
> >integration between the different tools.  Participants in the
> >collaboration may
> >not all have equal access in the process, for reasons of disability,
> >bandwidth,
> >firewalls, language, etc.
> >
> >Promising research is underway around the world, exploring innovative
> >technologies and user interfaces for collaboration. We are seeking
> >presentations
> >from the research community (academia, industry, government,
> consulting) on
> >state of the art work in document collaboration. In particular, we are
> >looking
> >for research which can address requirements expressed in the
> following use
> >cases.
> >
> >     Scenario: An international Open Source Software Project consists of
> > software
> >     developers from the US, Japan, Sweden, Thailand, Malaysia,
> China, and
> > India.
> >     Several developers have disabilities, including visual impairments,
> >     deafness, mobility impairment, and deaf blind. The project is in its
> >     planning stage and developers need to meet virtually to design and
> > create
> >     the software specification. Regular face to face meetings are not
> > possible.
> >
> >     The goal is the shared development of a web-based specification
> > document,
> >     with flow charts, diagrams, and screen layouts. Weekly
> teleconferences
> >     involve collaborative review and editing of the
> specification and its
> >     elements. Individuals must be able create and read annotations in a
> > modality
> >     appropriate to their needs. For example, graphical annotations or
> > notes (a
> >     circled word and added note), need to be visible to all
> participants.
> >
> >
> >@@ insert use case 2 ...
> >
> >Your position paper should describe your research and indicate
> whether it can
> >address some aspect of the scenarios presented in the use cases above, or
> >addresses other aspects of collaboration. If you are uncertain
> as to how your
> >work can meet specific use case requirements, it is acceptable to pose
> >this as a
> >question in your position paper.
> >
> >Goals:
> >
> >The mission of the Research and Development Interest Group (RDIG) is to
> >increase the number of Web-related researchers who incorporate
> accessibility
> >into their research design, and to identify projects researching Web
> >accessibility, and suggest techniques that may contribute to new
> projects.
> >The
> >desired outcome of more research in Web accessibility and awareness of
> >accessibility in mainstream Web-related research should decrease the
> >number of
> >potential barriers in future Web-related technologies.
> >
> >
> >Event Information:
> >
> >The format of the event is a teleconference, augmented by web-based
> >presentation material, and IRC. Registration is required for
> participation.
> Will there be an audience?  or just the speakers, moderator, and
> recorders.
> >Submission Information:
> >
> >Position papers are due by xx March 2003 and should be sent to the chair
> >( and W3C staff contact (  The papers
> >should
> >be short (approximately 2 paragraphs) and be submitted in HTML
> or plain text
> >format. Papers in other formats will be returned.
> Don't limit the submission in this way.
> A bibliography should be requested of citations to useful sources for the
> subplot that the submitter frames as their position for the
> event.  Resources
> that are available by Web links should be hyperlinks in the
> submission.  This
> should then be fronted by a brief statement summarizing:
> a) A rough scoping statement for the knowledge domain that the speaker
> would represent in the conversation
> b) What is known vs. not known in this domain that bears on the topic of
> the conversation
> c) What the interesting research questions would appear to be related to
> the topic of this conversation from the perspective of the submitter.
> The meeting record will both collect b) and tighten the framing of c).
> >The RDIG Planning Group (@@link) will invite the authors of particularly
> >salient
> >position papers to make a presentation at the event to foster
> discussion. The
> >invited presentations are to be approximately 15 minutes in
> length and should
> >include slides or other presentation materials. Authors are also
> required to
> >make the slides of their presentation available on the event Web site.
> This call has to be clear on the format requirements for
> presentations.  What
> level of description is required for visual materials?  What will
> the means
> be of sharing presentation materials as the presenter presents?  Does the
> presenter get to control events on at least one display window of
> the other
> participants?  Or do they only get to pass an URL for a page and the other
> people can be anywhere on the web at any moment?
> Will there be discussion?  How will the discussion be captured
> and published?
> This is a very practical matter.  The note-taking during the Device
> Independence
> Authoring Techniques was only half organized (in terms of
> preparedness with an
> organization) but it was an important function.
> I suggest that you make it a requirement of participation that
> people agree
> to be audio recorded and that you use iDictate or equivalent to
> create a text
> record of the discussion on the call. But this 'verbatim' would go only
> to the participants who could make changes in what the transcript
> said they
> said.  Then it would become part of the public record of the event.
> Do you have the labor hours allocated to do the editing work on
> the meeting
> record?
> >Position papers will be published on the public Web pages for
> the event, and
> >must be available for public dissemination. Submitting a position paper
> >comprises a default recognition of these terms for publication. The R&D
> >Interest
> >Group is chartered under the W3C Intellectual Property Rights policy
> >(, and
> >presenters and participants must acknowledge acceptance of this policy.
> >
> [1] Find an authoritative reference for this term in the Workflow
> literature
> or replace it with an equivalent that has such backing.
> The term 'document' is unfortunate in this regard other than to
> distinguish
> the topic from totally-ephemeral conversation.  There was a paper
> at XML2002
> that used a phrase something like "the age-old document/data conflict" and
> I would attest to the existence of such a tension and that a
> software design
> is more data than document in those terms.
> [2] As conceptualized in the book "Virtual Teams" by Lipnack and Stamps.
> [3] In the terms of the WHO disability taxonomy.  [The 'new paradigm' is
> too circular to be useful in framing this research dialog.]
> [4] Tech-editing rant:
> The initialCaps style indicates a Term of Art, a defined 'thing' which if
> this is the first, is a class of things, of which this is just the first.
> But the phrase with the caps is not the title of the series, it
> is the title
> of the instance.  This styling and phraseology combined is an error in the
> application of the initialCaps affect as generally understood in
> knowledge-industry writing.

Received on Tuesday, 25 February 2003 18:32:07 UTC