Developer's Day at WWW6: Notes from the Chair


The Sixth International World Wide Web Conference
April 7-11, 1997; Santa Clara, California, USA

Nick Ragouzis, Enosis Group, Chair, Developer's Day
nickr@enosis.com

http://www.enosis.com/services/WWW6/6w3devdayreview.html
June 30, 1997

For-public commentary sent to the author will be appended to this document.


--"Well, there sure are a lot of choices"
--"I wish there had been more about (several topics)"
--"Our session was great, what an involved crowd!"
--"What is with these corporate pitches?"
--"Those all-day technology tracks are great"
--"Some of these sessions are weak!"
--"I like that you'all included the non-technology tracks"
--"My session was empty, where was everybody?"

Over 65 sessions in the equivalent of 14 full-day tracks conducted by over 100 presenters comprised the program offered to the delegates to WWW6's Developer's Day. The scope of this program was a 6-fold extension of the Developer's Day program offered at the prior IW3C2 International World Wide Web conferences. As with each of the two prior programs, it represented both:

  1. a building on what had seemed to work before, and

  2. an exploration of new (to the WWW-series) concepts.


"--Was it a success?"

During three complete, and one partial walkthroughs on Dev Day I observed the sessions, and overheard and elicited the comments of delegates, presenters, and others. These comments, plus the reports by other WWW6 participants, in the practice common to open-ended market research, are coalesced into the selected prototypical responses presented above.


"--But, was it a success? Would you make changes?"

Yes. It was a success for those delegates who placed themselves in the sessions that delivered what was advertised. Even, or perhaps even more so, if the session was long, detailed, flexible to the audience's involvement and largely empty.

Yes. I would make many changes. The changes are rooted in two areas of discontent:

  1. I'd want to enlarge the set of delegates who experienced these successes; and,

  2. I'd want to be more convinced that the Dev Day program advanced the state and future of the WWW.


These Notes
As part of his notes to the WWW6 team regarding our Concepts Document, Bob Hopgood, the WWW5 Programme Chairman, wrote as follows:

"You almost certainly realise this but you should feel some obligation to making the life of the next conference organiser better. Good records of who attended, good feedback on tutorials, what you did wrong etc are really good input for the next poor soul!"

Bob certainly did this in his excellent Postscript to WWW5. I hope through these notes to discharge some of my obligation.

In the first part, WWW6 Dev Day Observations, I report a few observations about overall and specific aspects of the Dev Day program. Some of these will have relevant recommendations. In the final part, Recommendations, I speak more specifically on recommendations for future IW3 conference series Dev Days.


Understanding What's Important
Nothing in the commentary to follow will reach the fundamental importance as does a solid and resource-rich conference infrastructure to apply to the development of content and the conduct of production of the Dev Day program. By comparison with other professional conferences WWW6 Dev Day, in the tradition of IW3C Dev Days, lacked this to the extreme.

To compensate, the WWW6 Organizing Committee relied heavily on the goodwill and good work of many interested and dedicated professionals. The foremost among them were those professionals who actually prepared and presented their sessions. Even with this central contribution, however, the program would not have been developed or produced without the Herculean efforts of the small WWW6 Dev Day team. First among these are Jennifer Masek, SLAC. As Technical and Project Manager Jennifer was personally responsible for making the program happen. She was greatly assisted by Ruth McDunn, SLAC, and others unknown to me. Both Jennifer and Ruth jumped in (when they should have know better) and gave their all. Kathryn Hennis, SLAC, their manager in real life, enticed them into the Dev Day role, and then encouraged and assisted them in their efforts. For making the actual event appear effortless, and delegates welcome, no group of people can come before the renowned IW3-conference-series volunteers.

On behalf of the WWW6 Organizing Committee, and delegates to the WWW6 Dev Day program, I thank you all.





Part 1: WWW6 Dev Day Observations

  1. The Day, The Sessions, The Choices
    Friday, April 11, 1997, was WWW6 Developer's Day. Traditionally in the IW3C series, Friday is dedicated to the Developer's Day events. (WWW5 hosted the "SMEs Forum" on Friday, to a largely separate audience.) The WWW6 Dev Day program was rich in variety and choice:

    Table 1: WWW6 Dev Day Program Stats
     Count
    Tracks:14 
    Sessions:65+
    Presenters:100+

    New in WWW6 was the addition on Friday of History Day: 24 sessions in 4 tracks. Dev Day delegates were eligible to attend the History Day sessions. This combination presented in some time slots the choice of 16 sessions to an individual Dev Day delegate.

  2. Ticket Purchases
    This is not the official report of purchases of tickets to WWW6 or parts thereof. The official information is available from Christine Quinn, WWW6 co-chair. Although my report of the rough numbers, below, will likely differ significantly from those official numbers, it will serve to give observers a sense of the scale of the issues I am discussing here.

    Table 2: Rough Counts of Ticket Purchases
      --mon-- --tue-- --wed-- --thu-- --fri--
    Wksp/Tut: --200--        
    Passport:   -------------610---------------------
    TechPgm:   -------------570------------
    DevDay:         --150--
    History:         --???--

    The WWW6 Dev Day program was designed for the historical 60% portion of the originally planned 3,000 delegate WWW6 Technical Program attendance.

    According to the above estimates approximately: 610 + 150 = 760 delegates were eligible to attend all Developer's Day events. This gives us a proportion of Dev Day delegates to WWW6 general delegates approximately equal the historical ratio. From this we estimate Dev Day contributions to WWW6 revenues at $90,000.

    All WWW6 delegates, including Dev Day delegates, were eligible to attend History Day events.

  3. Attendance
    From my counts during the plenary plus my walkthoughs in the three main segments of the program (morning, early afternoon, late afternoon) I estimate the following attendance:

    Table 3: Session Attendance
     Delegate Count
    Plenary:600
    Dev Day Program:300
    History Day Program:100
    Lobby & Environs:120

    (Note: The Friday plenary was open to all WWW6 delegates.)

    Clearly, many delegates who were eligible to attend Dev Day decided to do other things. Especially after lunch and even more so after the afternoon break.

    This behavior was evident at WWW5 Dev Day. There, after monitoring almost all sessions during the week, the WWW6 team and WWW5 volunteers noticed the lower counts (nowhere near the 1000+ who were eligible) on Dev Day. We also noticed a shift from the (after a week) familiar faces and dress to a more formal crowd (thought to originate from the exhibition). In planning WWW6 Dev Day I concluded that this behavior was due to the locale -- Paris. I think now that I was wrong -- this is a pattern of behavior for which I should have made adjustments.

  4. Pulling Together The Program
    The WWW6 Dev Day Call for Participation is available at http://www6conf.slac.stanford.edu/devday/call.html. It describes a wide range of activities and topics, and describes the desired nature of the idealized Dev Day session.

    These characteristics were expected to be important in selecting a proposal for the program:

    • New or emerging research or technology
      As an expansion of a Technical Paper or Poster presentation, in follow-up to other such presentations (possibly in other forums - we looked at, among others: Hypertext, ACM CHI and CSCW, Living Surfaces, IEEE, AAAI, OOPSLA, OODB, Java, Netscape, Microsoft, Sun conferences and literature), and of material judged good but not yet ready for presentation status.

    • Potentially significant technologies or techniques
      With the objective of increasing access and awareness. Considered a wide range: from research to informal work to current and forthcoming packaged applications.

    • Standards-related work
      Especially integration across standards organization boundaries, including non-WWW.

    • Developer characteristic
      Hood-up, hands-dirty; from code to management.

    • A specific, viable proposal
      Especially if it was for more than a panel. This characteristic was especially important for filling out a track.

    Three further characteristics were known to be important in creating the program:

    • W3C Sessions, and W3C-staff Participation Sessions
      The W3C made a significant contribution to the program on WWW6 Dev Day. The W3C staff presented significant sessions on many aspects of the W3C standards. The W3C staff participated in other Dev Day sessions. The W3C staff, especially Rohit Khare, used their influence to attract (and transform) other viable program elements.

    • Workshop Reports
      The chairs of workshops were asked to give their reports within the Dev Day program -- some in the special Workshop Reports track, some integrated with other, related, sessions.

    • Access-Related
      Neil Scott, the chair of the WWW6 Access Committee, and chair of this track on Dev Day, reviewed candidate submissions and incorporated them as appropriate for his goals and Dev Day character.

    In spite of the Call, and the characteristics (expected or 'known') listed above here's what really counted:

    • Personal Contact with or by the Dev Day Committee
      Very few program-quality proposals were received through the Call or other distant solicitations. Only 4 were used. The overwhelming majority of the program content was the result of direct solicitation and facilitation. An important part of this was soliciting track coordinators and chairs -- who, unlike the often masters-of-ceremony chairs, were crucial in bringing content into the mix and utilizing content from the larger pool. The fifteen sessions (2.5 tracks) from the W3C are an important example of this. Apart from this it required significant effort in in-person visits, culling prospects from other conferences and industry participants, sharing contact lists, the assistance of corporate speakers bureaus, and email and telephone cold-call warfare soliciting, 'pitching', and shaping participation.

    • Personal History with the IW3C Series
      Those chairs who stepped forward, and program content not specifically solicited, were from professionals long associated with these conference series, the standards, the W3C, IW3C2, or WWW6 organizers. Even so, compared to the overall program, this was a small group.

    • Direct Interference in Program Content
      To whatever the move away from panels to substantive, exploratory and interactive program content was achieved it was due to the encouragement and pressure applied by the Dev Day team on the chairs and would-be presenters.

    In short, the Call was not an effective tool in constructing the content of the Developer's Day program. The Call did, however, have a role. A printed version of it was a good publicity tool. The many reinterpreted and personalized versions of the content of the Call were important for the personal solicitations. And, yes, a handful of the chairs and presenters did read it and ask relevant questions.

    Note that because of the nature of this programming effort, the emphasis was more on content development, and less on paper review. Refereed peer review of papers has not been, historically, an important part of Developer's Day; the presentations have never been collected into proceedings. Nonetheless, the track chairs or the Dev Day chair did review papers and work with proposal authors as required.

    The WWW6 Dev Day program is available at http://ice.www6conf.org/.

  5. Reception of the Program
    The challenge in drawing specific conclusions about the success of the program is rooted in the variety among the delegates. This variety is an important characteristic of the overall IW3C series. During the main part of the conference, the Technical Program, the unifying aspect is the novelty: new research, new standards, and new implementations of web fundamentals. When we come to Dev Day we reverse the focus: trying to assist developers in doing their job. That is: Dev Day gets personal.

    For WWW6 Dev Day I concluded that this required significant variety in the program -- to match the variety among the delegate's individual needs. This seemed to work. The key differences from WWW4 and WWW5 Dev Days wasn't the session count, but rather:

    • Full Tracks
      Key topics were explored in a full track. This is a significant difference from prior Dev Days, and accounts for a big part of the session count jump. One important area was the transformation of the W3C topics into robust tracks. VRML and Structured Documents (this time XML) were also elevated.

    • More Variety in Topics
      To meet the variety in interest, more topics were raised to track-level, and more tracks were added with general topic categories. Beyond the tracks mentioned above tracks such as the Access, Workshop Reports, Technical Publishing, and Product Design were important to their audiences.

    • Fewer Panels - More Specifics, More Interaction
      This both served to make the session more concrete and allowed them to be flexible to audience needs.

    Did this variety attract and hold more delegates than a traditional IW3C-series Dev Day? I don't know. Would those who attended the new-topic tracks and sessions have been just as satisfied in attending tracks and sessions on the traditional topics? I don't know; some delegates were quite specific that they appreciated these other program choices, and wanted them to continue.

    Related to this is how delegates responded to the additional choices offered them by the simultaneously running History Day program. Here I think we have a specific demonstration of the importance of variety for Dev Day. I witnessed and overheard several Dev Day delegates making their schedule work to allow them to go to specific History Day events (in whole and in part). The Dev Day delegates moved fluidly back and forth between these programs. The two programs complimented each other in attracting and retaining delegates. I believe this same phenomenon was at work within the Dev Day program.

    Overwhelmingly, but not universally (I had specific dissenters!), I believe that the Dev Day delegates that stayed for the program felt they had received a valuable program. Clearly the delegates had more content available (by measure of simultaneous sessions, and total sessions) for their registration purchase than in prior IW3C-series conferences. Whether in WWW6 the staging economics were prudently and productively balanced for delivering this value to the size of Dev Day audience we eventually attracted is questionable.

 

Part 2: Recommendations

I'd like to set a backdrop before I try to describe what it is that I would do again or differently. These recommendations cannot be taken as mandates for future IW3C-series Dev Days. Rooted in WWW6 as they are, these recommendations become contextless for future conference Dev Days. Further, with respect to future Dev Day program development, to the extent they work to support some initiative that a future conference wants to attempt, great. To the extent these recommendations seem to contradict such a future initiative, ignore them.

  1. Positioning Dev Day
    Almost every challenge considered above, and recommendation made below can find its roots in the need for better and stronger positioning of Dev Day. What is its purpose relative to the Technical Program and the other tracks that run in a IW3C-series conference? What is its purpose relative to other conference developer activities? Whatever the answer, it must be strongly and widely broadcast from the initial program announcements throughout the conference itself. This means the investment of human and financial capital. Confusion in this impacts the attraction of content and the attendance at Dev Day. And, as is typical in poorly positioned services, those who do attend remain unclear about whether they got what they expected.

    Several activities are important in this regard:

    • Promote Dev Day as part of the efforts to develop and select content for the Technical Program and other conference programs. Be sure that the International Program Committee and the paper reviewers know what you're looking for. See more about this in Coordination with Technical and Other Programs below.

    • Promote specific Dev Day program elements in advance -- preview them if possible.

    • Cultivate future presenters and delegates through 'smart' promotion. Help the IW3C2, W3C, and Conference Host representatives script their pre-conference writing and at-conference formal remarks to include solicitation of future Dev Day participation (as chairs, as presenters, and as delegates).

  2. The Program and Production Model
    The general conference organization, under the guidance of the Dev Day team, should perform all the planning and execution of the production aspects of Dev Day. The Dev Day team should be focused primarily on content development. This parallels a general recommendation for the overall conference, set out in part in Subject: Rethinking the conference planning and operations model?, a July 17, 1996, correspondence from part of WWW6 planning.

  3. The Call
    • As mentioned above, the Call had its uses, but not primarily as a generator of content. Perhaps that will have changed as a result of the experience with the WWW6 Dev Day, or will change from stronger efforts at positioning future Dev Days.

    • The dates and contact information are important.

    • Content submission format is important -- if only to help uniformly answer the usual questions. We had thought we may collect and publish the material from the sessions. I suspected that both presenters and delegates would have an interest in this. They did. I was wrong, however, to think we could publish a proceeding from the submissions. In practice very little content (2 sessions) was submitted that was eventually taken to presentation. This was a strong side-effect of how we wanted the program sessions to be conducted -- we didn't want fixed, rigid, presentations. Perhaps future conferences will be better prepared to collect the actual program content (and other session media) -- post-conference edited versions of this content might be of wide interest. (See also recommendations about Dev Day Proceedings, below.)

    • The Recorders and Respondent ideas, although seen in other conferences, was entirely lost in this effort. See below the recommendation about Session Conduct.

    • Because of the solicitation aspect of pulling together the program, the list of content types (case histories, expert advice, etc.) and activity types ( paper, panel, forum, tutorial, etc.) were of use mostly to the WWW6 team, not to potential and actual submitters.

    • More important to the content and activity lists would be specific information addressed to potential track chairs and track coordinators. (The semantics we internally used: Coordinators put the track together, are responsible for gathering and managing the content, presenter information, day-to-day working with the Dev Day team. Chairs lead the effort and lead the day. Often these were the same; where there were co-chairs of a track, one of them was often the track coordinator.)
      • What content will they be responsible for?

      • How will they be expected to review it?

      • What are their responsibilities for delivering abstracts for the track and the individual sessions?

      • How will the Dev Day team and other conference committees be involved in reviewing and approving the session proposals?

      See also recommendations about Scheduling, below.

    • Elevate above any general lists the few specific characteristics of the proposed sessions that are desired or undesired. The WWW6 Dev Day call should have been much clearer about the undesirability of straight panels and straight paper presentations.

      The characteristics of the most successful sessions seemed to be: "applied" (applied research, applied (new to year-old) standards, applied design); and "integration and interoperation" (of standards, of techology, of development tools, of products). These have in common that they focus on technology that is at the threshold of wider implementation.

    • Contests and awards were a hit -- in concept only. Individuals at several corporations, also sponsorship candidates, were initially interested. The result was, however, nil. It was a concept entirely foreign to the IW3C Dev Day series, and since, as mentioned above, so much depended on folks with prior IW3C-series association, and specific Dev Day team effort, there just wasn't time to make these properly happen.

    • The demonstrations, case histories and code walkthroughs were a hit -- in reality.

    • The tutorial and hands-on sessions were not so significant -- beyond the Access Track that is. We didn't develop enough of them. The few that we did have were poorly attended, possibly because they were on topics and at levels not appropriate for the audience, and possibly because of our failure to effectively promote them.

    • The 2 'soft' tracks were strongly supported. The delegates to the Design track and the Publishing track were enthusiastic supporters for the continuity of the tracks. These tracks also attracted a significant audience, and had among the highest attendance counts in the day's ending session. (Disclosure: I was the chair and coordinator of the Design track. It was, however, the presenters and delegates that made it valuable and interesting.)

  4. Session Conduct
    Several things expected, and a few in evidence, at Dev Day might be worth further exploration:
    • Delegates wanted more program time earlier in the day. (This seems to be directly related to those delegates who were participating in the one-topic tracks.) The upshot:
      • Shorten the opening plenary

      • Make it possible for sessions to run through lunch. Drop the luncheon talk. Make it easier for delegates to get lunches without breaking the 'spell' of the session. (The box lunch concept -- if not the actual food! -- at WWW6 would have useful for this had the food and beverages been delivered to the rooms.)

    • The one-topic tracks were very flexible in the conduct of the sessions, and even the order of the content. This should be encouraged. At WWW6 Dev Day we should have removed the dais from rooms that had them. We should have rearranged the seating, removed the tables, made the environment more suitable for brainstorming and exploration. Many sessions in effect did this. These tracks were more like one-day symposia. Fostering this evolution will, I think, be attractive to presenters and delegates alike.

    • Both presenters and delegates wanted longer 'standard' session intervals. We tried to fit our program into a fixed format: 3 periods in the day, each containing 2 45-minute sessions. In many cases the time actually wanted and needed was 30, 60 and 120 minutes. Unlike the Technical Program where each period has several speakers giving short, 15-minute, talks with questions to follow, these are mostly one-topic, one-speaker periods. We made the adjustments. In some cases these adjustments caused delegates to lose visibility (in the program) of a session. This is related to the above item (viz. flexibility in one-topic tracks).

    • The features mentioned above make it more difficult for delegates to switch sessions. The breaks aren't as specific. The speakers aren't sitting on a dias. With significant audience participation the 'speakers' aren't necessarily those in the program. In addition to setting expectations about this, I suggest that a specific, detailed, syllabus, with complete biographies, be available in every session and track. Look for other methods to help newcomers understand what's going on and encourage their participation.

    • Having prepared the syllabus and biographies, the chair comments and introductions at the beginning of each session should be significantly collapsed.

    • Delegates are truly sensitive about leaving sessions before breaks. One result of the foregoing would be to make breaks less predictable. Compensate for this.

    • With all of the up-front compression of sessions (above), look to the possibility of not starting a new session after 3:30 or 4:00. At WWW6 Dev Day folks stayed in the sessions they were in. But not many showed up for new sessions starting after the 3:30-4:00 break.

    • Better, clearer, advance detailed information about the Dev Day program would help structure and enrich the actual sessions.

  5. Coordination with Technical and Other Programs
    Several opportunities exist here:
    • The presenting of the Workshop Reports in the Dev Day program was important and useful. I recommend more emphasis by the Workshop chairs on what specifically they want to accomplish in the Dev Day session. These should be more than simply recitations and a general discussion of the events of the Workshop. The chair and other presenters of topical Dev Day tracks should work with the Workshop chair on integrating an included Workshop Report into the work of the track. It might be useful to request that the Workshop chairs detail in their workshop proposals, or in separate Dev Day proposals, what they intend to deliver and receive from the Dev Day audience, and what session format they intend to use on Dev Day. (This might also help direct the work of the Workshop.) Additional promotion should be performed before and during the conference to make general delegates aware that the Workshops will be discussed on Dev Day.

    • I believe a similar mechanism might be useful in linking forward the tutorials.

    • I feel we missed an opportunity to bring more content forward from the technical paper and poster presentations. We did this with only a handful of cases. I think we missed opportunities for papers (submitted and withheld) that were new to the web but had been published recently elsewhere (disqualifying them from the Technical Program). Additionally, some of the presenters of papers I saw (at WWW6 as well as WWW5) could have benefited from participation in Dev Day sessions. And their participation might have given initiative to different or new Dev Day sessions and tracks. This was also true of Posters. I believe this opportunity could be seized by more cross-promotion and cross-development. And full mutual involvement by the conference's content producers.

  6. Scheduling
    These recommendations address the process of collecting and developing the program. The basic recommendation is: don't use a simple "Submit and Accept" protocol for Dev Day program development. The interactions are too complex for this. These recommendations assume the adoption of many of the preceding recommendations. That few Dev Day programs actually result from the call are reason enough to understand this. The additional interaction with track coordinators and other program issues will also reduce the relevance of such an approach. Here are some features which a process might exhibit:
    • Issue a call for track chairs and coordinators. This should be clearly separate from the call for session content (although possibly part of the same page). It's dates will well-precede the dates for the Dev Day content and all other conference program content (especially the Technical Program). Be specific about track chair and coordinator duties (in developing content, and session conduct), and how they'll work with the Dev Day team. (This call might be coordinated and combined with the need for chairs within the special tracks during the week's program.)

    • The call for session content should leverage the progress for the call for track chair and coordinators. Revise this call as tracks are proposed, and accepted.

    • As you accept track chairs and coordinators put them into the content flow. The only use of an acceptance date for this is to notify declined proposals for tracks. A good deadline for this might be a few weeks before the Technical Program submission deadline. (For WWW6 Dev Day this would have simply been an internal date -- most of the chairs were individually solicited.)

    • The submissions for session content should be considered simultaneously by the Dev Day team and by the relevant track chairs and coordinators.

    • The key date is the deadline for track chairs and coordinators to make complete proposals for their track's sessions. In preparing their proposals, the chairs and coordinators should have worked with the Technical Program committee and paper reviewers. Declined material from the Technical Program should be reviewed by the Dev Day committee before the Technical Program committee notifies the declined paper authors. (To make this productive and fast, the Dev Day team should be aware in advance of the papers and their review status.) This deadline (for Dev Day track chairs and coordinators) should come after the Technical Program committee has made its selection and possible shifts from the Technical Program and Posters to the Dev Day program have been identified.

    • The Technical Papers and Posters, and the Tutorials and Workshops will still be going through change. Meanwhile, the Dev Day team and the track chairs and coordinators should still be considering which of the other conference content is 'right' for further featuring on Dev Day. As occurred with WWW6, some of the Dev Day-developed content might be shifted into the main program. At some deadline this will be complete.

    • All through this period individual session proposals will have been reworked and accepted or declined. The deadline for individual session submissions, and for notification will equal or precede the above according to program and logistic needs.

    • The last significant program-level deadline is for completed abstracts. These come from the track chairs and coordinators, and from the accepted paper presenters not integrated into a topic-level track.

    The WWW6 Dev Day program development wasn't very much like the submit-and-review process used elsewhere in the program. It was subject to some of the hurdles more common in commercial conferences. In particular: the operating through single-point-of-contacts (SPOC). These can sometimes be helpful. It is common to partner with the SPOC for getting overall organization commitment and as a partner facilitator -- but to end-run these folks, working through personal and otherwise known contacts, to assure that the right folks are found and involved. These tactics are necessary in developing the greater part of the Dev Day program, with importance in direct proportion to the amount of dependent Dev Day content at risk.

    The deadline structure I've identified above is intended to assist in this. In particular, by requiring that the actual content-responsible person (and not the SPOC) becomes the individual track chair or coordinator early in the process you will increase your chance of early closure on track and overall program content. Generally the SPOC is happy to see this happen too.

  7. Dev Day Proceedings
    There was a lot of noise and confusion about publishing proceedings from the non-Technical Program sessions, including the Dev Day program. The primary issue was the singular focus on book-level isolation as the one true method of assuring the purity of the technical papers from non-peer-reviewed content such as tutorials, workshops, industry, Dev Day. This is self-delusional nonsense (qv. various ACM and Hypertext conference proceedings). The secondary issue, made more severe by the first, was cost: larger book? two books? Another, more fundamental, delusion was that there would be Dev Day material to publish pre-conference. I was wrong about that--there wasn't.

    Future Dev Day programs may develop content suitable for this pre-publishing. But for this Dev Day, the pre-conference content for many of the sessions wouldn't have been suitable for printing: demonstrations, walk-throughs. Forcing it might even have made the sessions more rigid. I believe the greater value will come from transcriptions of in-session content--the charts, diagrams, Q & A, URLs, action item lists, areas of opportunity, etc. I would like to see this go in the post-conference proceedings, even if it is only linked from the CD-ROM or otherwise electronic proceedings. In addition to the service this provides Dev Day and other delegates post-conference, I believe it will help attract track chairs and coordinators (although it will add to their tasks), and presenters.

    I recommend that all conference delegates receive as part of the materials they get with their conference materials, a complete listing of the Dev Day abstracts.

  8. Tools
    I recommend that you take advantage of whatever collaborative and coordination tools you can to continually and directly involve all direct Dev Day folks (e.g., track chairs and coordinators) plus other folks (e.g., chairs of workshops, technical paper reviewers) in the program development process.

    To be clear about this: I would have gotten great utility from having at hand (already ready to go) a tool that allowed me to show, at any time, several versions of the status of development of the Dev Day program. My source base of this information, a kludged HTML database (not being an XML savant!), contained information on candidate chairs, confirmation status, deadlines (mostly missed), probability assessments, contact information, speculative and partial abstracts and titles, and other official and unofficial data. As part of soliciting, promoting, and forming the content I was repeatedly preparing and distributing or posting special extracts: possible tracks for potential chairs, possible pairings for similar sessions, etc., of the same session, track, and overall day, and logistics for the Dev Day team.

    In addition, although you might not need anything special to accept and cache submissions, you are very likely to need something to automatically handle the abstracts and official contact information. Something that will make it possible to directly publish them.

    Speaking of tools: ICE. ICE, or a similar tool, offers a significant opportunity to help the Dev Day team manage this process. To do so you'll need a way to allow track chairs and coordinators to update the content of 'their' track descriptions and individual sessions. These updates should pass a Dev Day team review before being committed in the public server.

    In addition to the above there are three additions required in ICE to better support Dev Day:
    1. Individual Dev Day Tracks
      The lack of these was the source for the most complaints about understanding the Dev Day program, in advance and then online at the conference.

    2. Individual Track Descriptions
      Each track should have a collective base where common aspects of the track may be managed and presented.

    3. Distributed Update Rights
      The ability for the Dev Day team to give rights to others (track chairs, session authors). These would include rights to give rights. Rights should be atomic, or at least categorical (e.g., to protect session location and time from change).

  9. Session Technical Requirements
    Unlike the majority of the Technical Program, many Dev Day sessions or events required special, custom technology. This is especially true of demonstrations, hands-in sessions, and hands-on tutorials. Beyond the IW3C-series technical paper approach, look to more traditional conference methods (we-provide, you-provide; by component category) and system implementation methods to plan and confirm this.

    A sample of the quick-and-dirty form we used to email these requirements back and forth and around (and around), is available, with data still in it, at: http://www.enosis.com/services/WWW6/techrqmt.html.

  10. Space Planning
    In addition to altering the room arrangement as recommended above, delegate behavior would indicate that you plan for fewer to attend than paid. From experience we might guess that less than 50% of those who paid for Dev Day actually attended. Using the traditional 60% Dev Day subscription rate, this might argue for planning the space at the level of 30% of the space in the main Tuesday through Thursday program. The constraint here is the number of tracks. At WWW6 this meant, compared to the main program, more rooms, more capacity, not less. The rooms with the necessary technology weren't reducible.

    One caution. It would have been a mistake to assume that just because the WWW6 Dev Day delegates aren't attending their sessions that they won't need lunch.

  11. A Different Developer's Day, A note to WWW8
    In the WWW6 Concepts Document, available at http://www.enosis.com/services/WWW6/6w3concepts.html we considered a fundamental change to the Developer's Day and Tutorial and Workshop program. We considered running these as during-the-week programs. We saw good benefit resulting from the interaction between the Technical Program, the Workshops, the Tutorials and Dev Day.

    Principally, when the potential for interaction with the Technical Program content is tapped, properly structured Dev Day tracks and sessions would build on the short "15-plus-5" minute often fixed-talk exposure that the Technical Program provides. It would give more structured and detail interaction opportunities to presenters and delegates--which is one of the main things asked for by presenters and delegates alike.

    Though finding significant support from the WWW4 and WWW5 producers and delegates we interviewed, WWW6 wasn't ready for the experiment. Two important supporters of a serious look at this change were key players in WWW5: Bob Hopgood, Programme Chairman, and Yves Peynaud, Conference Manager. They wrote:

    From Yves.Peynaud@inria.fr (Yves Peynaud)


    " - I really love:
    ...
    o the Tutorial track and DDay track, as opposed to days (with the same remark as above [pertaining to delegate endurance being 2 to 3 days]). Take care to clearly position and display the target audience for DDay and Tutorials sessions."

    Yves' comment points out a benefit not thought of in preparing the Concepts Document. That is of engaging delegates in Developer-related activities during the 2-3 day period they attend the conference, rather than imposing an endurance requirement (that they make it to Friday, and are willing to suffer the Friday afternoon travel challenge).

    From: frah@inf.rl.ac.uk (Bob Hopgood)


    "(14) Tutorial track spread through the week is done effectively at a number of Conferences so good idea."

    It is probably too late to alter the structure of the WWW7 program. But this change should be considered seriously for future programs. It is a prominent paradigm among technology (if not research) conferences.