\label{sec:futurework} \label{sec:hatching}
In looking for ways to manage and encourage serendipity, we are drawn to the approach taken by the design pattern community \cite{alexander1999origins}. describe the typical scenario for authors of design patterns:
“You are an experienced practitioner in your field. You have noticed that you keep using a certain solution to a commonly occurring problem. You would like to share your experience with others.”
There are many ways to describe a solution. Meszaros and Doble remark,
“What sets patterns apart is their ability to explain the rationale for using the solution (the ‘why’) in addition to describing the solution (the ‘how’).”
Regarding the criteria that pattern writers seek to address:
“The most appropriate solution to a problem in a context is the one that best resolves the highest priority forces as determined by the particular context.”
A good design pattern describes the resolution of forces in the target domain, and applying the solution achieves this resolution of forces. The design pattern itself is valuable because it achieves something further: it encapsulates knowledge in a brief, shareable form (often with meaningful relationships to other patterns).
The steps in this description match the schematic outline of the key features of serendipity, as illustrated in Figure \ref{fig:pattern-schematic} (compare Figure \ref{fig:1b}). The discovery/invention of a new design pattern would seen as serendipitous according to our model, though the SPECS
To van Andel’s assertion that “The very moment I can plan or programme ‘serendipity’ it cannot be called serendipity anymore,” we would reply that we can certainly describe patterns (and programs) with built-in indeterminacy. Figure \ref{fig:va-pattern-figure} presents an example, showing how one of van Andel’s patterns of serendipity can be rewritten as a design pattern using the standard template.
-1
Van Andel’s example – Post-it Notes
– You run a creative organisation with several different divisions and many contributors with different expertise.
– One of the members of your organisation discovers something with interesting properties, but no one knows how to turn it into a product with industrial or commercial application.
– Create a space for sharing and discussing interesting ideas on an ongoing basis.
– You suspect it’s possible that one of the other members of the firm will come up with an idea about an application; you know that if a potential application is found, it may not be directly marketable, but at least there will be a prototype that can be concretely discussed.
– The Successful error pattern rewritten using this template is an example of a similar prototype, showing that serendipity can be talked about in terms of design patterns.
In future work, we would aim to build a more complete pattern language along similar lines, and show how this language can be used to transform raw data into “strategic data.” The example pattern describes a scenario that is quite close to Pease et al.’s description of an online system that gathers new modules over time, and for which, periodically, new combinations of modules can yield new and interesting results. Developing experiments along these lines may help prepare the groundwork for the more involved development projects discussed in the current paper. Patterns of serendipity, like the one in Figure \ref{fig:va-pattern-figure}, offer useful heuristic guidelines for human programmers and convey a sense of our long-term plans for serendipitous computing systems.