This wiki space contains archival documentation of Project Bamboo, April 2008 - March 2013.
What are these demonstrator projects, how are they initiated, and how are they produced? What are the capabilities and limitations of this piece of the overall Bamboo endeavor?
The working group demonstrators are constructed for two purposes: to support the discussion and analysis activities of the working groups, and to reflect and test the results of that discussion and analysis. Examples of the former type might be a drawing of a concept, or a storyboard showing the steps of a particular service or activity, or the installation of a dozen existing "type X" tools put side by side to allow comparison, or a website which shows how existing web services can be used to remix existing data. Examples of the latter type might be a new web service which exposes an existing tool or service in a new way, or one which allows for a new capability. Demonstrator projects, particularly those that involve coding or which otherwise actually do something, are not necessarily designed to be used beyond the end of the Planning Project. They might spin off into projects of their own, or they might inform the construction of a more formal application in the future, or they might retire to a quiet life in the country. This is both a freedom and a limitation.
If the leaders or advisor of a given working group determine that a demonstrator is called for, they contact the Demonstrator Project Manager (me) for a consultation. In general, I encourage working groups to think primarily about what they want, and not worry as much about how it might be accomplished. We're fortunate to have access to a wide range of programming, systems, visualization, and design skills. Too much analysis before talking to the project manager can actually be a hindrance in the creation of the demonstrator – please feel free to bring me in as early as you like.
A working group might simply articulate a problem to me (when I'm doing X, I can't do Y) – in that case, the demonstrators would then be the creative response of the developers as to how that problem might be solved. A working group might focus entirely on a result (at the end of the day, I want to have X, Y, and Z all smashed together, and I don't care how it gets that way as long as it's easy). A working group might take a narrative approach (first this, then this, and then this). A working group might use a demonstrator to express an idea, such as a hierarchy, relationship, or process. A working group might use a demonstrator to illustrate a particular set of principles – for example, what does a mindful application look and feel like, versus an unmindful one?
Demonstrator projects utilize a few tactics to produce results which are both rapid and useful:
Size to the rule of 3: We are considering projects which might take 3 hours, 3 days, or 3 weeks. The demonstrators need to generally be part of the between-workshop progress of the working groups, and there's not enough time between workshops to allow for long delays between idea and demonstrator. However, a small number of larger projects (the 3-month size) may be initiated within the two sponsoring institutions. These larger projects will generally illustrate broader concepts than fall within the scope of the theme-specific working groups, or serve as proofs of concept for underlying technologies and architectural components.
Embrace Failure & Iterate: The best demonstrator projects might well be those that completely fail to reflect the ideas of the group (because this would illustrate a new perspective on the topic, help to tighten the expression of the idea, or at least show the difficulty of communicating about it), or which are an accurate reflection but which are utterly undesirable for actual use (because this would allow the group to abandon a given line of thinking and explore alternatives). We should all expect that the process of developing these demonstrators is iterative (i.e. a version is created, released for comments, and then discarded or revised). Working groups must be willing to give feedback in a timely fashion to allow for this cycle.
Skip the hard parts: The most important feature of these projects is that they demonstrate ideas, and are not necessarily designed for use beyond the end of the project. Therefore, we intend to avoid spending time on those pieces of a project which, while necessary for a public deployment, don't serve the idea and are time-consuming to implement. Examples of shortcuts might be substituting simple authentication or algorithms where authentication or the algorithm are not a critical part of what is being demonstrated. We might implement the project in a language that allows for rapid development in exchange for a result which runs a little slower or would be difficult to maintain long-term.
Demonstrator projects must be useful to the planning process, and the result of cross-institutional interest.