|--"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
- a building on what had seemed to work before, and
- 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?"
It was a success for those delegates who placed
themselves in the sessions that delivered what was
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:
- I'd want to enlarge the set of delegates who
experienced these successes; and,
- I'd want to be more convinced that the Dev Day
program advanced the state and future of the WWW.
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
On behalf of the WWW6 Organizing Committee, and
delegates to the WWW6 Dev Day program,
I thank you all.
- 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
The WWW6 Dev Day program was rich in variety and
Table 1: WWW6 Dev Day Program Stats
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.
- Ticket Purchases
This is not the official report of purchases of
tickets to WWW6 or parts thereof.
The official information is available from
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
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.
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|
|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
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
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.
- Pulling Together The Program
The WWW6 Dev Day Call for Participation is available at
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
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,
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
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
- 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
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.
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
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.
- 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
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
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
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).
- 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
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.
- 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
I suspected that both presenters and delegates would have an
interest in this.
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,
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
(See also recommendations about Dev Day Proceedings,
- The Recorders and Respondent ideas, although seen in other
conferences, was entirely lost in this effort.
See below the recommendation about
- 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
The WWW6 Dev Day call should have been much clearer about
the undesirability of straight panels and straight paper
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
- 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
(Disclosure: I was the chair and coordinator of the
Design track. It was, however, the presenters and
delegates that made it valuable and interesting.)
- 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.)
- Shorten the opening plenary
- Make it possible for sessions to run through
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
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
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
- 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
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
One result of the foregoing would be to make breaks less
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
- Better, clearer, advance detailed information about the
Dev Day program would help structure and enrich the
- 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
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
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
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
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
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
- The submissions for session content should be
by the Dev Day team and by the relevant track chairs and
- The key date is the deadline for track chairs and
coordinators to make complete proposals for their
In preparing their proposals, the chairs and coordinators
should have worked with the Technical Program committee and
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
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
- 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
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
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
In particular: the operating through single-point-of-contacts
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
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.
- 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
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.
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
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
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:
- 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.
- Individual Track Descriptions
Each track should have a collective base where common
aspects of the track may be managed and presented.
- 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).
- 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
and forth and around (and around), is available, with data
still in it, at:
- 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.
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.
- A Different Developer's Day, A note to WWW8
In the WWW6 Concepts Document, available at
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,
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
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: email@example.com (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
But this change should be considered seriously for future programs.
It is a prominent paradigm among technology (if not research) conferences.