Book Contents and Structure
What is the expected content and structure for book chapters? Are the templates for cases and patterns recommendations for descriptions within chapters, or are they the actual chapters?
The cases and patterns solicited in the call are the expected chapters of the book. These will be augmented by section introductions and scenarios, authored or initiated by the section editors.
We are not seeking free-standing self-contained chapters in traditional format.
What is the rationale behind the sectioning?
These sections emerged from the discussions among the book editors, and later between the editors and the section editors. While they do aim to provide a broad canvas, they admittedly reflect a particular reading of the science of technology enhanced education and stem from our common set of values.
Is this structure fixed?
We are committed to a genuine collaborative authoring process. Consequently, very little is fixed. Nevertheless, we do not foresee major changes in structure. Any change, small or large, will have to originate from the group of authors, be clearly justified, and accepted by the group.
Why this particular structure?
What are case stories?
What is the right scope / scale of a case story?
A case story should provide a "thick description" of a concrete event. The exact bounderies of an "event" is a matter of author discretion, but preference should be given to depth rather than bredth of description. As a rule of thumb, a case should focus on the solution of one problem in one situation.
What are Design Patterns?
What are "forces"?
The idea of analysing a problem as a configuration of "forces" goes back to Christopher Alexander's original theory (Alexander, 1964
), where he proposed
that any design problem can be described as a configuration of multiple
interacting "forces" - objectives, constraints, etc. According to Alexander, the most general formalisation of process of design is to isolate a set of interacting forces, and attempt to align those that are in conflict.
Many pattern writers find it useful to break down the problem their pattern addresses into such forces, and describe it in terms of the tension between them. Such problem descriptions take the form of "I want to achieve A and B but have to comply with constraint C". For example, "I want to walk to work, I want to get there dry, but it might rain" (solution: take an umbrella), or "I want to listen to music but don't want to wake my neighbor".
How do I refer to related patterns?
In your initial submission, please include links to other patterns on-line and bibliographic references for patterns which have been published.
Once the set of cases and patterns for the book has stabalised, you will be asked to adjust these, to make a clear distinction between links to other contributions in the book and to resources elsewhere.
We see connectivity as an important aspect of design patterns, and encourege links to high-quality resources which have not yet been published in academic channels.
Process and Procedures
Why is the deadline so tight?
We ascribe to the open-source mantra of "release early, release often". Consider your submission a version 0.1 of your contribution. This is not an invitation for half-baked ideas, but for solid work which needs some polishing. We want to allow a long process of shepherding and cross-commenting, to provide this polishing. We also want the contributions to be available on-line early so that authors can review each others work and we can converge to a coherent and consistent style.
Why the link between case stories and design patterns?
Why only one pattern per case / one case per pattern?
We request that for each pattern, at least one supporting case will appear in the book. Other cases can be referenced if they have been published elsewhere.
We expect additional links to emerge from the collaborative authoring process.
Do I submit to a particular section or the the book in general?
If your contribution clearly addresses a specific section, please contact the section editors directly. Otherwise, please contact the book editors and suggest which sections you think your contribution would fit best.
Can scenarios be included as part of a submission?
Scenarios are intended to demonstrate and validate the patterns. Therefore, scenario development will start only after the set of included patterns has stabilised.
What about the theoretical foundations?
Please make a note of any theoretical issues you see relevant to your cases and patterns. Once the contributions for each sections are selected, the theoretical discussion will be developed collaboratively by the section authors, and orchastrated by the section editors.
What is the status of the existing content on-line?
The content on-line is in "perpetual beta", and will remain such up to and after publication of the book. If you want a stable, properly edited, proofed and formated product - buy the book.