# Exploring Capturing Approaches in Shared Fabrication Workshops: Current Practice and Opportunities

Clara Rigaud, Gilles Bailly, Ignacio Avellino, Yvonne Jansen

► To cite this version:

Clara Rigaud, Gilles Bailly, Ignacio Avellino, Yvonne Jansen. Exploring Capturing Approaches in Shared Fabrication Workshops: Current Practice and Opportunities. Proceedings of the ACM on Human-Computer Interaction, 2022, Issue CSCW 2022, 6 (CSCW2), 10.1145/3555116. hal-03695911v2

HAL Id: hal-03695911

https://hal.sorbonne-universite.fr/hal-03695911v2

Submitted on 31 Aug 2022

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Exploring Capturing Approaches in Shared Fabrication Workshops: Current Practice and Opportunities

CLARA RIGAUD, Sorbonne Université, CNRS, ISIR, France

GILLES BAILLY, Sorbonne Université, CNRS, ISIR, France

IGNACIO AVELLINO, Sorbonne Université, CNRS, INSERM, ISIR, France

YVONNE JANSEN, Univ. Bordeaux, CNRS, Inria, LaBRI, France

Capturing content of fabrication activities is the first step for producing knowledge resources and an integral part of maker culture. As a secondary task, it conflicts though with the fabrication activity, and thus it is often forgotten and knowledge resources end up incomplete. In this article, we investigate different dimensions of content capture for knowledge resources in fabrication workshops. Based on past work in this area, we first propose a framework through which we identify two research directions to investigate. From these, we derive three dimensions to explore in more depth: The *number* of capturing devices, their *feature variety* and the degree of *automation* of each feature. We then explore the design space resulting from these three dimensions with the help of a design concept and an online survey study (N=66). Results show (1) a variety of needs and preferences justifying feature variety and multiplicity, (2) challenges in defining the right degree of manual and automatic control, and (3) the socio-technical impact of cameras in a shared space regarding privacy and ethics. We conclude with discussions on the benefits and vulnerabilities of equipping fabrication workshop with distributed camera-based capturing devices and offer opportunities for design.

**CCS Concepts:** • **Human-centered computing** → **Human computer interaction (HCI)**.

**Additional Key Words and Phrases:** capture, fabrication workshop, makerspace, knowledge resources

**ACM Reference Format:**

Clara Rigaud, Gilles Bailly, Ignacio Avellino, and Yvonne Jansen. 2022. Exploring Capturing Approaches in Shared Fabrication Workshops: Current Practice and Opportunities. *Proc. ACM Hum.-Comput. Interact.* 6, CSCW2, Article 391 (November 2022), 33 pages. https://doi.org/10.1145/3555116

## 1 INTRODUCTION

Fabrication workshops<fnref n="1" /> are shared spaces enabling rich interactions between people using various machines to create, build, or repair, and discuss, share, or learn from each other. While many interactions in such spaces are local and direct between physically present people, others are inherently indirect and asynchronous, as they take place across time between people in different physical spaces through the exchange of *knowledge resources*. Producing rich knowledge resources relies heavily on capturing content about the activities happening in fabrication workshops. Capturing content requires, however, to switch between a fabrication activity, one's main focus, and capturing, a secondary task [36]. Consequently, it is often forgotten [82] or incomplete [77], resulting in knowledge resources which focus too much on the eventually successful outcome and leave out

Authors' addresses: Clara Rigaud, clara.rigaud@sorbonne-universite.fr, Sorbonne Université, CNRS, ISIR, Paris, France; Gilles Bailly, gilles.bailly@sorbonne-universite.fr, Sorbonne Université, CNRS, ISIR, Paris, France; Ignacio Avellino, ignacio.avellino@sorbonne-universite.fr, Sorbonne Université, CNRS, INSERM, ISIR, Paris, France; Yvonne Jansen, yvonne.jansen@cnrs.fr, Univ. Bordeaux, CNRS, Inria, LaBRI, Bordeaux, France.

© 2022 Copyright held by the owner/author(s). Publication rights licensed to ACM.
This is the author's version of the work. The definitive Version of Record was published in *Proceedings of the ACM on Human-Computer Interaction*, https://doi.org/10.1145/3555116.

<footnote n="1">¹such as maker spaces, fab labs, or hacker spaces</footnote>
most of the garden of forking paths explored to get there. Consequently, the resulting knowledge resources are missing opportunities for others to learn from the explored paths [9].

Past work has proposed a variety of systems which focus on facilitating and integrating the steps through which knowledge is produced and exchanged: content capturing, storing, retrieving, editing, sharing, and reusing [15, 17, 22, 28, 50, 75]. While such systems simplify the production of knowledge resources, they are somewhat monolithic in the sense that they offer a complete solution and may not integrate well with people's existing capturing, editing or curating habits some of which makers may want to retain. In opposition, the use of more generic devices such as smartphones or Gopro cameras still exposes makers to constraints as they require extra time and effort to set up a scene. In this article, we explore the space between these extremes focusing in particular on the *capturing* step.

We first present a framework, structured around a set of questions known as the 5W1H (*why, what, when, where, who*, and *how*). For each of these questions, we analyzed past work to identify a set of properties with which we can describe and compare both existing and new research. We then use this framework to generate two research directions which until now have not received much attention in the context of fabrication workshops: supporting capturing of diverse and distributed activities, and exploring automation versus user control. While it is well established that fabrication workshops encourage diverse activities which happen distributed within these spaces [5], existing capturing approaches generally only support at best one of these properties. Partially automated approaches are also in themselves not new [3, 79], yet there has been very little work exploring potential risks and benefits of automated control capturing approaches in fabrication workshops. To investigate these two directions, we derive three dimensions along which capturing systems can vary: multiplicity (number of capturing devices), variety (feature homogeneity between capturing devices), and degree of automation of features.

The remainder of the article explores these three dimensions. For this, we first developed a design concept, termed CAPUSH. The central idea of CAPUSH is to facilitate the conception of different types of camera-based units, each equipped with an adjustable set of manual and automatic features based on our framework. We conceived five different unit types varying on the three dimensions. Our hypothesis is that a single type of capturing device with a set level of control is not sufficient to address the diverse needs when producing knowledge resources in fabrication workshops.

To test our hypothesis, we ran an online survey with 66 participants who report on their current capturing practices and, after watching a video sketch of the different unit types, on how these unit types and their respective features may suit their capturing needs. Results confirm makers' difficulties when capturing content in fabrication workshops and suggest that while many of the features of CAPUSH are well received by the majority of respondents and many express support to deploy a CAPUSH-like system in their local workshop, the concept evoked also important concerns which need to be considered when installing camera systems in a community space.

From our investigation of content capturing in fabrication workshops to produce knowledge resources, we identify and elaborate on the following opportunities for design:

* Favoring multiple community capture units across a fabrication workshop and accessible to all makers, increasing flexibility, mobility and reminding to capture content.

* Enabling makers to delegate control in a predictable fashion over some properties of capturing devices, combining manual and automatic approaches to respect individual or situational preferences, with the goal of reducing physical and cognitive load.

* Considering privacy and ethics by providing visibility and control of what is captured, both to the maker initiating a capture but also to others in the vicinity of a capture.
## 2 FRAMEWORK: CONTENT CAPTURING FOR KNOWLEDGE RESOURCES IN FABRICATION WORKSHOPS

Our first contribution is a framework (summarized in Table 1) that results from our literature analysis on content *capture* to produce knowledge resources in fabrication workshops. We constructed the framework around the *5WIH* questions: Why to capture? What to capture? How to capture? When to capture? Where to capture? Who captures? We first clarify terminology before detailing the different dimensions of the framework.

Fabrication workshops, commonly referred to as makerspaces, Fablabs, or hackerspaces, are shared spaces providing access to fabrication machines and tools with which a diverse group of people can carry out a wide range of activities that involve creating, building or repairing [11, 58, 66]. These spaces can be found both in public institutions (universities, schools or libraries) and private institutions. Because of the diversity of users, the multitude of purposes, and their open access spirit, communities emerge and collaborative work leads to learning through sharing of experiences and knowledge [61]. In the context of this article, we use the term **knowledge resource** to refer to any form of support for the storing, sharing, and reuse of knowledge relating to fabrication workshops. Such resources encapsulate knowledge to different extents, including manuals, tutorials, how-to guides, or portfolios, and they can take different shapes including blogs, wiki entries, or videos, often made publicly available through dedicated platforms [41, 71, 72]. We consider **content capture** as recording any aspect related to a fabrication project, such as images, videos, audio, a 3D object definition, or fabrication machine parameters. We focus in this article on content capture for the creation of knowledge resources in fabrication workshops and do not aim to cover the entire literature on context-aware computing [7]. In the following sections, underlined words are used to refer to the sub-dimensions of our framework.

### 2.1 Why to capture?

Capturing content is the establishing step in producing knowledge resources [49], which is essential in the philosophy of fabrication workshops [32, 40, 55]. Knowledge resources are produced at different levels for different purposes. At the community<fnref n="2" /> level, a common objective is to teach by sharing both explicit and tacit knowledge, so that others can learn by replicating, remixing, or extending previous projects [52, 60]. Those who were able to benefit from others' sharing efforts may be motivated by reciprocity, wanting to give back to the community [41, 58, 60, 71, 72]. In contrast with synchronous face-to-face sharing, which is common practice in fabrication workshops [47], producing and sharing knowledge resources is not bound to a specific time and space: the resources can be used asynchronously by people outside the workshop [71].

At the individual level, one objective is to build an identity through demonstrating skills, inspiring others and communicating ideas [41, 50, 56, 58]. Makers also produce resources for themselves: they may anticipate later reuse (e.g., resuming a paused activity) [60, 71, 82], or use them when seeking feedback from peers such as colleagues or supervisors [23, 35, 46, 48]. Knowledge resources can therefore act as a reflexive tool [19, 20, 24, 27, 28] which lets makers make sense of their experiences and get an overall overview of a process. A special case and motivation for capturing activities is to provide feedback during a fabrication activity, generally to guide makers in achieving their goals, for example, to dynamically communicate process information such as task progress and safety warnings [37], the maker's level of mastery of a tool [26], or to suggest an improved technique for the current task [12].

Finally, capturing content is also useful at the organisational level to extract *meta* knowledge resources and support the management of fabrication workshops [47, 53]. For example, systems

<footnote n="2">²Underlined terms indicate properties of our framework. They are summarized in Table 1.</footnote>
can collect information about ongoing projects or provide overviews of the fabrication workshop activities and machine usage for decision support and space planning [26, 53].

While capturing content is beneficial at different levels (*why*), there are two main barriers that prevent many makers from capturing content (*why not*). First, capturing content, and more generally producing knowledge resources, takes times, is difficult and tedious [82]. Second, makers are focused on their primary activities of fabrication, and producing knowledge resources remains a secondary task. Thus, pausing the work to take a picture or a video breaks the flow and thus is often left as an additional task to come back to at the end of a project or simply forgotten [77, 82]. These barriers lead to not only fewer resources, but also resources which are incomplete or less rich than what makers wish for and thus are often not reused [77, 80].

## 2.2 What to capture?

Fabrication workshops host a wide range of activities from 3D printing over textile knitting, wood working to microcontroller programming which may require to capture different types of data. *Images* and *videos* are popular data types and, when enriched with text, build the basis of many knowledge resources [41, 72]. Indeed, photos and videos can often efficiently communicate an idea, illustrate the steps required to create an artifact or demonstrate how an artifact can be used. However, photos and videos are used differently. Videos are often considered more useful to capture processes [16], for instance, when communicating the gradual progression of a movement, which is complex to accurately recompose from static images. They are also more engaging [41]. While this may reflect habits and opinions in the context of fabrication workshops, past work has shown that for some learning tasks, static images combined with text are more appropriate than videos [31], and that static diagrams can effectively communicate assembly instructions [1]. However, other formats may be relevant as well such as *audio* [50], *annotations* [13, 15] or design files [72].

Going beyond these universal types of capture material, many activities can be recorded in the form of structured data specific to the fabrication context. For example, Troxler [74] introduced FabML, a specification format based on XML to capture and exchange fabrication activities. FabML aims to provide a structured language to capture an activity together with relevant contextual *information* such as a personal identification, the name of a project, the processes and methods involved, the used machines (e.g., 3D printer), tools (e.g., screw driver), components, materials and the type of source files as well as corresponding spatio-temporal data such as location or timestamp [57], tags (which can add semantics to captured content) [64], information about the environment [37], or serial output [38].

## 2.3 How to capture?

The choice of technologies is often informed by *What* one wants to capture and *Why*. For instance, capturing which serves for purposes other than the creation of knowledge resources, such as recognizing mastery of tools [26] or suggesting improvements on one's currently used technique [12], may rely on Inertial Measurement Units or physiological sensors. For the creation of knowledge resources, the most prolific technologies are vision-based sensors. Capturing visual activity traces is often done using *personal devices* like smartphones and tablets. They provide a quick and effective way to produce high quality images, and makers already bring them along into the workshop [16, 36]. Youths are especially comfortable using them to capture and share on platforms such as *YouTube* or *Instagram* [44, 56]. Because these devices have several sensors readily available, they can also be used to capture additional content such as audio for orally annotating a video simply by speaking when the camera is recording [50]. However, makers' personal devices also have important limitations. First, used on their own, they generally constrain *hands-free* manipulation [15] and thus limit a maker's ability to work and record at the same time. Thus, as
detailed by Keune et al. [36], most smartphones require mounting devices which can be costly to set up and suffer from inconveniences such as the screen going to sleep or conversely the device running out of battery. More importantly though, due to the fact that they are ubiquitous multi purpose devices, makers are likely to forget about their presence, and consequently forget to capture their work [36].

Some fabrication workshops provide makers with *community devices* to capture content, often in the form of dedicated stations specifically for capturing image and video. They generally include one or multiple cameras pointing towards an area reserved for capturing artifacts during a project, some form of lighting system to ensure good visibility, and in some cases additional mechanisms to facilitate the annotation of a project. Examples of such stations include: Dodoc [28], which features different modules including a lamp and a fixed camera pointing down at a documentation area to record video, still images, or build animations; Protobooth, which uses either a turntable [38] or several fixed webcams pointing toward a platform to capture different point of views of a prototype [21]; Fabnavi [78], a camera/projector assembly mounted on top of a table; DIY mounted toolkits to hold a smartphone or tablet and enhance the salience of the capture device [36]; and Spin, a camera combined with a turntable to generate animated GIFs of a 360° overview of a fabricated object [76]. While such stations are promising in many aspects, they do not provide *mobility* and thus constrain to work were the station is installed or to interrupt their work and transport artifacts over to the station. Lastly, special devices can capture and transform other kinds of data into video streams such as depth information (e.g., from a Microsoft Kinect) as done in Duplotrack [30] for recognizing assembly tasks, or temperature fields through infrared cameras in the case of blacksmith crafts [4].

## 2.4 When to capture?

Capturing content can happen at different moments in a fabrication workshop. When the focus is on showcasing a final product [76], capturing happens *after* an activity. However, the most relevant time to capture content for generating knowledge resources is *during* an activity, as this is when makers can keep traces of a process, their reasoning and the decisions they made at the time of the activity [19, 75]. Yet, capturing while focusing on a primary task imposes a break of flow as it requires to switch from a primary to a secondary task, which adds time, and, most importantly, needs to be remembered. It is common to postpone or simply forget to capture the process and only capture the result [77, 82]. As a consequence, important (mis)steps [77] go missing and only the successful ones are captured [34, 45, 50, 75]. The result is that many knowledge resources are not adapted or reused [77, 80]. Finally, some types of content, such as sketches, drawings and CAD files, are created *before* they can be fabricated and can be captured for their later use in a tutorial or documentation [22, 35, 80].

## 2.5 Where to capture?

Fabrication workshop are often laid out so that different types of activities happen in different areas [5]. Thus, makers need to move between areas such as a workbench where they are sketching and performing 3D modelling to a machine area where the 3D printer is located. Inspired by Gong et al. [26], we identified three types of placements for capture systems. First, cameras or sensors can be attached in the *environment*, in a fixed fashion, e.g., mounted to a wall, or in a mobile fashion, e.g., on a tripod [15, 78]. *Fixed cameras*, such as downward-oriented cameras attached to the ceiling or on an auto-pole can provide an especially appropriate view for areas dedicated to specific activities [36] or in the case of documentation stations such as DoDoc [28]. Although fixed cameras provide a stable video result [78], they may not be appropriate for all activities, for instance, makers might want to capture a video of their artefacts at different locations (e.g., in
front of a green screen or in a quiet place), where no cameras are installed. Relying only on fixed cameras would require a very high number of installed cameras, especially for large spaces. Mobile cameras offer more flexibility as they can be moved around in the space. Nonetheless, they also have drawbacks as their use increases the risk of occlusion by a person or an object, especially when using a tripod [15]. Additionally, tripods require extra manipulations, are obtrusive, and can hinder the mobility of people in a workshop. Second, cameras or sensors can move with a *person*, for instance, by holding a smartphone, recording sensor data from a smartwatch [2, 26], or wearing a GoPro<fnref n="3" /> on one's head. Head-mounted cameras enable hands-free interaction and provide a first-person perspective [16, 51] which can improve performance on assembly [39] and learning [44]. However, footage from person cameras often lacks stability in comparison with cameras in the environment [15], which tend to provide higher quality videos. Finally, sensors and cameras can be attached to a *machine* such as a 3D printer, a laser cutter or a drill bench, capturing when and how specific machines are used [26].

## 2.6 Who captures?

In the context of this framework, *who* refers to who initiates and controls content capture and related properties. In most cases, makers manually capture content by *positioning* and *orienting* a camera, adjusting its *focus* (even if this one is often automatic) and *triggering* (start/stop) the recording. They also often manually *manage* content, for example, by uploading it to a shared repository [63]. *Manual* control requires *immediate* *feedback* of what is being captured to check whether the objects of interest are in the field of view of the camera and whether the camera focus is correct [15]. Makers receive this feedback by annexing screens such as smartphones [50], by using dedicated screens [28] or by using augmented reality through video-projection [78] or wearable devices like Google Glass [15]. However, manually setting these parameters can be difficult when working, especially when the cameras are not directly accessible [15]. *Automated* capture has the potential to reduce cognitive and physical demands on makers, to let them focus on fabrication (their primary task) [15] and to free their hands to manipulate objects [36]. However, only few prototypes rely on this approach. For instance, Spin [76] automatizes the *orientation* of a camera by the means of a turntable to create animations of a 360° view of an object. Protobooth [38] creates 3D representations of an object via photogrammetry. However, we are not aware of approaches that, in the context of fabrication activities, automatically orient a camera to keep a moving tool or person in focus as was done, for example, in the context of recording moving presenters [81]. Some systems store automatically the content in a centralised place, following a specific organisation to make the retrieval easier. Centralised repositories can then automatically create links between records (e.g., tool usage or interactions), data-entries or projects [62]. For instance, Erichsen et al. [21] proposed a system that automatically captures timestamp meta-data associated with a project, enabling the visualisation of the different prototypes' iterations. Some argue that automated capture needs to be approached carefully though. For example, Keune et al. [36] raise two concerns: First, the process of taking a picture or recording some part of a process is the fruit of a reflection that is important, especially in a learning context, and should be made consciously; secondly, automated capture is likely to lead to a longer curation process due to a larger amount of captured content to review. Automated techniques to create knowledge resources have also been explored to facilitate the work of the maker during the steps after the capture of content. Such explorations include automated image processing and documentation authoring [50] or automated video-tutorials based on the activity or movements recognition [2, 12].

<footnote n="3">³https://gopro.com/</footnote>
## 2.7 How to Use This Framework

<table><caption>Table 1. Comparison of different vision-based capture systems using the framework from section 2. For comparison we also include how the use of a generic smartphone and a collection of GoPro cameras compares with more specialized systems and we also include a description of the design concept introduced in subsection 3.2. Brackets indicate that a property depends on the concrete device choice or implementation.</caption><thead><tr><th></th><th></th><th>Generic smartphone</th><th>Collection of GoPros</th><th>Dodoc</th><th>Fabnavi</th><th>Spin</th><th>ShowHow</th><th>Document While Doing</th><th>Protobooth</th></tr></thead><tbody><tr><td rowspan="3">Why</td><td>Community benefits</td><td>■</td><td>■</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Individual benefits</td><td>■</td><td>■</td><td>■</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Organisational benefits</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td>■</td></tr><tr><td rowspan="6">What</td><td>Pictures</td><td>■</td><td>■</td><td>■</td><td>■</td><td></td><td>■</td><td>■</td><td>■</td></tr><tr><td>Timelapses</td><td>(■)</td><td>(■)</td><td>■</td><td>■</td><td>■</td><td></td><td></td><td></td></tr><tr><td>Videos</td><td>■</td><td>■</td><td>■</td><td>■</td><td></td><td></td><td></td><td></td></tr><tr><td>Sound annotations</td><td>(■)</td><td>(■)</td><td>■</td><td></td><td></td><td>■</td><td>■</td><td>■</td></tr><tr><td>Text annotations</td><td></td><td></td><td></td><td></td><td>■</td><td>■</td><td>■</td><td>■</td></tr><tr><td>Contextual meta-data:</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td rowspan="4">How</td><td>Project ID</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Tools/machine</td><td></td><td></td><td></td><td>■</td><td></td><td></td><td></td><td></td></tr><tr><td>Location</td><td>(■)</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Kinds of systems:</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td rowspan="3">When</td><td>Community device</td><td></td><td>■</td><td>■</td><td>■</td><td>■</td><td>■</td><td></td><td>■</td></tr><tr><td>Personal device</td><td>■</td><td>■</td><td></td><td></td><td></td><td>■</td><td></td><td></td></tr><tr><td>Properties:</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td rowspan="4">Where</td><td>Mobile</td><td>■</td><td>■</td><td></td><td></td><td></td><td>■</td><td>■</td><td></td></tr><tr><td>Multiple</td><td></td><td>■</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Hand free</td><td></td><td></td><td>■</td><td>■</td><td>■</td><td>■</td><td></td><td>■</td></tr><tr><td>Environment</td><td></td><td></td><td>(■)</td><td>■</td><td>■</td><td>■</td><td>■</td><td>■</td></tr><tr><td rowspan="3">Who</td><td>User</td><td>■</td><td>■</td><td></td><td></td><td></td><td>■</td><td></td><td></td></tr><tr><td>Machine/Tool</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Automated properties:</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>orientation</td><td></td><td></td><td></td><td></td><td>■</td><td></td><td></td><td>■</td></tr><tr><td></td><td>position</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>contextual meta-data</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td>■</td></tr><tr><td></td><td>content management</td><td></td><td></td><td>■</td><td>■</td><td>■</td><td>■</td><td></td><td>■</td></tr></tbody></table>

We illustrate a key use of the framework in Table 1 which provides an overview of the 5W1H dimensions (column 1), the properties within (column 2), and how different systems compare to each other (remaining columns). System designers can consider systematically each dimension and the associated properties, to describe and analyze a capturing system they implement, compare
it to existing systems, and, most interestingly, to identify gaps and **generate** systems with novel capabilities. To illustrate we use Dodoc [28] as an example and showcase the framework's descriptive and comparative power. Dodoc's main goal is to support reflection (*Why*: individual benefits) by capturing pictures, timelapses<fnref n="4" />, video, and sound annotations (*What*: images, videos and sound) through a shared station that can be used hands-free (*How*: hands-free community device). The station can be used both during and after fabrication activities (*When*: during and after), however, since it is located at a fixed place (*Where*: environment), makers may need to interrupt their activities to capture content *during* an activity. Finally, makers need to position and orient the camera manually, whereas Dodoc manages content automatically (*Who*: manual orientation and position, but automatic content management).

We can also compare Dodoc to other systems using our framework: Table 1 illustrates this for generic smartphones and a selection of five other systems which together provide an overview of the breadth of different capturing approaches. It is worthy of note that the comparative power of the framework lies in that it lets designers compare dimensions which were not necessarily explicitly addressed in the articles describing each individual system. The generative power lies in that the framework elicits which dimensions and properties are currently underexplored, which future work may find valuable to facilitate the communication of new contributions. Of course, the framework does not include all potential future properties and classes within each of the 5W1H dimensions, but it can easily be extended as needed to demonstrate the novelty of some future contribution.

## 2.8 Takeaways and Research Directions

Based on our own analysis of the framework and comparison between existing systems, we highlight key takeaways that show divergences and alignments between making practices and capturing systems, and constitute potential future research avenues (generative power). First, on the *Why* dimension we observe that while community and individual benefits are commonly used to motivate the capturing of content in fabrication workshops, organizational benefits such as providing an overview of the fabrication workshop activities [53] are also important but less often considered. Then, on the *What* dimension, we find that despite the wide range of devices, the capture of visual content such as pictures and videos is most prevalent, alongside text and sound annotations. Regarding *How*, we observe that dedicated *community devices* providing hands-free operation are a popular choice. This may be due to the observation that makers tend to forget more easily to capture when using their personal devices [36]. With regard to *Where* capturing takes place, we observe that most opt for a placement somewhere within the *environment*, whereas worn captured units are less explored and direct placement on machines or tools remains to be explored further. Concerning *When* capturing takes place, many systems aim to increase support *during* the activity, since leaving it for *after* the activity risks leaving out potential mistakes, which could be valuable to include for future makers learning about this activity [77]. Lastly, regarding *Who* controls capturing, most approaches are primarily manual, with previous work providing little guidance on the degree of automation of capturing systems. For the remainder of this article, we focus on two needs that we believe are of particular essence for makers.

***Supporting Diverse and Distributed Activities.*** There seems to be a paradox on the "*How*" dimension. On one side, we observe that a large number of systems are dedicated to very specific activities, often restricted to a limited area, such as a workbench, or to small objects and prototypes.

<footnote n="4">⁴Timelapses are animations of a sequence of pictures taken from the same view angle during a certain period of time and showing the accelerated evolution of a scene.</footnote>
They are generally composed of a single camera installed at a specific location, such as Dodoc [28] or Fabnavi [78] that are built as stations to capture the different steps of an assembly task by taking pictures from the top of a workbench. However, a fabrication workshop involves *diverse activities* happening at different locations and machines *distributed* throughout a workshop [5]. Some prior work proposed to reuse existing mobile devices [15, 50] which are more appropriate for distributed activities, but these still rely on a *single* camera which implies that makers need to move it between the different areas in which they work and adjust its positioning and other parameters based on the specific needs of the different activities they carry out. Our work aims at overcoming the trade-off that exists between systems focusing on a dedicated activity and systems focusing on distributed activities.

***Exploring Automated versus User Control.*** In the “Who” dimension, we believe that there are missed opportunities. We observe that most approaches rely on *manual* controls (one exception is camera focus which is generally controlled automatically). Although manually controlling capture properties can help makers build expertise and reflect in and on action, the main activity of making is cognitively and physically demanding and requires, among other things, creative work, vigilance, and coordination with others. Therefore, *automating* at least some of the parameters listed under Who in Table 1 seems promising to let makers focus more on their main activity. This has not been studied much in the context of fabrication workshops, and it remains unclear which feature(s) should be automated and when. We argue that the *Who* dimension deserves more research to explore how makers could benefit from mixed-initiative approaches [3], i.e., combine the advantages of both manual and automatic control.

## 3 EXPLORING VISUAL CAPTURING APPROACHES

The previous section was about *analyzing* capturing systems in the fabrication workshop. This section is about applying that analysis to explore the *design* of possible future systems. As the last section illustrates, the design space is enormous. We thus narrow our focus on visual capturing (*What*), and particularly on three dimensions which emerged from the analysis of the framework: from the research direction “Supporting Diverse and Distributed Activities” we retain the number of camera units and the number of features for each camera unit, and from the research direction “Exploring Automated versus User Control”, we retain the degrees of automation of different features.

In this design space, we consider to start with two extreme cases. First, we consider a system with *multiple* identical basic capture units (a simple camera). Each capture unit is dedicated to a given location (station) and a given perspective. Given the nature of the fabrication workshops and the range of activities, this approach would require a large number of units and coordination between them (e.g., to stop one and start another). A second extreme case would be a single *intelligent* capture unit with *various* and *intelligent* features offering them the capacity to both determine and adopt the best configuration (e.g., location and orientation) depending on the activity, the maker, or the context. However, a single unit (per maker) would in many cases not be enough. For example, a maker may want to capture and monitor the working of a CNC machine while capturing the assembly of a circuit on a nearby workbench. On a more practical note, this approach is likely to be difficult to implement and deploy for designers, and makers might be frustrated if the accuracy is not high enough and abandon the technology.

### 3.1 Methodology

Between these two extreme cases is a rich space of possibilities which can be described by the mentioned three dimensions: **multiplicity** (number of camera units), **variety** (the different features
for each unit *type*) and the respective **degree of automation** for each feature. These design choices can influence the additional mental workload for makers and their capacity to reflect in and on action. Such a rich space is challenging to explore. While evaluations with real physical prototypes are valuable when the concrete design choices for the implementation of these prototypes are clear, there is a risk of participants focusing on low-level implementation issues for cases where the possible design space is large. Greenberg and Buxton called this “local hill-climbing” [29] and emphasized, together with Tohidi et al. [67], the utility of “design sketches” which demonstrate some aspect but stay intentionally vague or non-committal on others.

Our approach is in line with their argument and similar to the one taken by Vitale et al. [79], who upon describing their design space developed five design concepts and evaluated them with interviews only showing video sketches to participants. In our case, we use a design concept and a set of five conceptual units exemplifying areas within the design space. We also generated a video sketch to illustrate how these units could integrate in a fabrication workshop. We expect that the use of video sketches instead of actual prototypes reduces the risk of “local hill-climbing” as it has been used successfully in prior work [54, 79]. Similar to Vitale et al. [79] and Tohidi et al. [67], we include multiple unit sketches to give participants an idea of the breadth of the design space. While Vitale et al. base their findings on interviews, we use an online survey to reach a larger number of people.

We describe below our design concept and the five unit types intended to exemplify different areas of the design space. Table 2 summarizes how these unit types compare using the framework introduced in the previous section. The remainder of the article then focuses on the survey and our findings.

## 3.2 CAPUSH: Design concept

The CAPUSH concept builds on the assumption that a single capture unit is not sufficient to address the diverse needs when producing knowledge resources in fabrication workshops. A key aspect of CAPUSH is thus to consider a fleet of capture units (*multiplicity*) composed of different unit types with different features (*variety*). Some of these features can be automatized (*degree of automation*). We now detail the concept.

**Capture unit.** The focus is on visual capture, thus each capture unit needs to be equipped with a camera to capture images or videos (*what*) in high quality. A unit is meant to be affordable and easy to build, ideally using materials commonly available in fabrication workshops. It should also be light, small, and easily customizable and extendable. Because they are affordable, *multiple capture* units can be distributed in the fabrication workshops and make them accessible to all makers. Moreover, an incidental benefit is that distributed capture units throughout the space can attract the makers’ attention [36] and remind them to produce resources. Because they are light and small, makers can easily grab them and move them from one location to another one. Because they are customizable, it is possible to create different types of unit with various features to respond to the specificities of different activities.

Each capture unit should be connected to a local network to provide a centralized access to the control of the units and to have them put captured content directly in a local repository. All captured content should be automatically enriched with contextual meta-data, such as which unit recorded the content and where it was located (*what*). Such meta-data could then serve to enrich later knowledge resources generated with the captured material, for example, using (semi)automatic tools to generate such resources [15, 50, 75].

**Features.** Since we want units to be customizable, CAPUSH is based on a set of features with
<figure><img src="image_2.png" /><figcaption>Table 2. Description of the five examples of camera units derived from CAPUSH in terms of content captured (what), location (where): machine / environment / person, mobility and hand free properties (how) and levels of automation (who) (orientation, position, contextual content capture). For the who dimension, □ specifies whether the control is manual only and ■ whether the control can be manual and automated.</figcaption></figure>

<figure><img src="image_3.png" /><figcaption>Fig. 1. Physical mockups of the five unit types: fixed, pan-tilt, clamp, head-mounted, and table bot.</figcaption></figure>

which a unit can be extended. In this article, we focus on four features related to the dimensions of the framework. As illustrated in Table 2, all capture units capture the same content (what) but vary according to where they can be located (the environment, on a machine, or worn by someone), how they enable the capture and who controls each of the features. In particular, who refers to the degree of automation: the position and/or orientation of a camera unit can either be controlled by the system (automatic) or a person (manual). Similarly, both by the system and the user can initiate the capture of contextual meta-data. By combining the different features, it is possible to derive a large variety of camera-based units.

## 3.3 Unit Types

We focus here on five unit types whose features are summarized in Table 2. Figure 1 shows mockups of the different unit types and illustrates how they could be used. These units aim to coexist in a fabrication workshop, each adapted to different activities. Below, we describe the functionalities of each of them.
<figure><img src="image_4.png" /></figure>

**Fixed camera.** The fixed-camera unit is a camera attached (permanently) on a machine (such as a laser cutter) or a workstation (such as a soldering station) with a fixed, pre-determined viewpoint, focusing on the area of interest, such as a 3D printer bed, or a laser cutter work area.

<figure><img src="image_5.png" /></figure>

**Pan-tilt camera.** The pan-tilt camera is an extension of the fixed camera. It is also installed permanently in the environment but its camera is mounted on a pan-tilt assembly enabling rotations around the pan and tilt axis for more control over the focus area. The control of the pan-tilt assembly can be automatic or manual. The latter lets makers control the orientation of the camera either through physical manipulations or through a (virtual) joystick interface displayed on a computer or smartphone's screen. Automatic control permits to track a specific tool or object while performing an activity, that is, objects of interest can remain in focus even if the makers move them. This approach is especially useful to capture a process including the displacement of pieces and tools on a workbench.

The three following units are mobile, enabling makers to freely transport and place them wherever they are working. While attached units can store their location as meta-data which only needs to be set once after installation, portable units need to be able to detect their location to provide this type of meta-data. We discuss how this could be achieved in section 8.

<figure><img src="image_6.png" /></figure>

**Clamp camera.** A clamp camera is a mobile extension of the pan-tilt camera. It includes a battery pack and is mounted on a clamp, so that it can easily be moved and attached in the *environment* in different locations to get different points of view. This unit can thus be used to capture a scene from flexible points of view, providing the makers with a quick and simple way to set up their scene.

<figure><img src="image_7.png" /></figure>

**Head-mounted camera.** The head-mounted camera is an extension of the pan-tilt camera mounted on a headset, similar to the clamp but worn by the *person*, enabling a first person viewpoint capture. By attaching the unit once to the head, the maker can move around in the space wearing the head-mounted camera to go from an activity to another.

<figure><img src="image_8.png" /></figure>

**Table bot.** Table bot is a Pan-tilt camera mounted on a small robot. Either the maker or the robot can decide the best position and orientation for this camera unit. In particular, the robot can track pieces (e.g. circuit board) or tools (solder) and move around on a table to maintain the distance between the objects of interest and the camera constant.

<figure><img src="image_9.png" /></figure>

**Meta-data.** The concept of CAPUSH includes a local repository where all captured content (pictures and videos) can be associated with tags. These tags can either be added by makers, for example, by entering a project name, the project owners' names or any annotation that makers may find useful. As these manual tag entries can require some effort from the maker, the concept includes the generation of automated meta-data as tags, including the location of the captured content (e.g., "woodworking area", "electronic workbench"), machines or tools identified in the stream (e.g., "screwdriver", "3D printer",...), and timestamps.

# 4 STUDY: UNDERSTANDING CURRENT PRACTICES AND EXPLORING FUTURE OPPORTUNITIES

We designed an online survey study to better understand current capturing practices in fabrication workshops, and to explore in how far the dimensions exemplified in the five unit types correspond to
the capturing needs of makers to identify challenges and to provide directions for which prototypes of the design concept should be developed further.

The study received research ethics approval from the Research and Ethics Committee of our institution.

## 4.1 Research Questions

We designed our study with three guiding research questions in mind:

(1) What are people's current capturing practices across diverse activities?

(2) How do makers envision the impact of the different dimensions of a shared capturing equipment's features on their capturing practices?

(3) What are the potential issues that need to be considered for different types of equipment?

## 4.2 Survey Design and Approach

We implemented the survey on a personal server running LimeSurvey 3.25.21 and structured it in four parts:

(1) **Introduction**. The first page was dedicated to inform potential respondents about the purpose of the study and ask for their informed consent.

(2) **Background and demographics**. The second page asked general questions concerning basic demographics (age group, country of residence, profession) as well as background information on how long they have been using shared fabrication workshops, what roles they have had in these spaces (maker, manager, teacher or instructor, other), what kind of activities they tend to do (such as electronics, 3D printing, woodworking, etc), and what their collaboration habits are.

(3) **Current capturing practices** contained two pages. The first one focused on current capturing habits and asked what kind of tools respondents currently use, how they find their captured content again, how satisfied they are with their current habits, and if and where they share any captured content online.

The following page focused on two of the activities respondents indicated on page 2 (background and demographics). These two activities were dynamically selected according to the frequency at which the respondent had indicated capturing content about. Respondents were then asked for each what kind of record they generate when doing that activity, whether they are more interested in capturing the process or the result, and what kind of problems they encounter when capturing content from these activities.

(4) **Exploration of the design concept**. The last page explores the different aspects of our design concept and the compatibility with different types of activities. Respondents are first asked to watch a 3:23 min video (included in the supplemental material) explaining the concept and unit types. In the video, the different concepts were presented one-by-one as low-fidelity animated drawings like those in subsection 3.3. We provide an example of the visual style of the video in Figure 2. Accompanying the visuals, a voice-over and subtitles describe how the units are supposed to work, including the different degrees of freedom of the actuated and mobile units, as well as the automated and manual tag entries with location of each unit and object detection and tracking. Mock-ups of the units (Figure 1) were also included to illustrate more concretely how the units could look like. Finally, the video introduced the idea of a local repository and the use of tags to retrieve the captured content. Respondents were then asked to express how much they like each feature with the option to provide details for each. Then respondents indicated for one of the two activities used on the previous page, how having access to this envisioned system may or may not change how and what they would capture.
<figure><img src="image_10.png" /><figcaption>Fig. 2. Stills from the video shown to respondents. (A) shows the different units located in the workshop to illustrate multiplicity and variety. (B) illustrates the pan/tilt unit with manual control and (C) introduces automated position with tool tracking. (D) shows (conceptually) how the content captured from the units ends up in a local repository enriched with contextual meta-data (location, tool,...).</figcaption></figure>

The survey concluded with a range of questions inquiring if they would want such a system to be installed in the workshop they frequent, if they would use it if it was installed there, and how they would personally improve it. Finally, we asked if they can think of situations where they would not want such a system, and offered space to leave further comments if they desired. The supplemental material includes the raw responses to the questions from this page.

Based on piloting, we estimated that it would take between 10 and 20 minutes to fill the survey. However, we also noted that providing more details in the many optional free-text response fields could considerably increase response time. We therefore added a warning on the information sheet page to make potential respondents aware of this. Nonetheless, we observed that respondents spend considerably more time than we expected (mean time 25 minutes [22, 29 minutes, 95% CI]).

## 4.3 Participant Recruitment

We aimed to reach a broad range of respondents and thus gathered emails from the fablabs.io<fnref n="5" /> website which includes people from all around the world. We sent out a total of 1,635 invitation emails, which resulted in 1,033 visits and 66 complete responses. The survey was available during 3 weeks. Figure 3 provides an overview of basic demographic information about the 66 respondents.

## 4.4 Analysis and Report

The survey included a combination of questions where response options were either in the form of Likert items, multiple choice answers, or free text entry. We report responses to Likert items

<footnote n="5">⁵https://www.fablabs.io</footnote>
<figure><img src="image_11.png" /><figcaption>Fig. 3. Overview of demographics and background of our respondents.</figcaption></figure>

and multiple choice questions visually, in the form of bar charts for multiple choice questions and in the form of stacked, aligned bar charts for Likert items. Note that the sum of responses to multiple choice questions sums up to more than the number of respondents. For Likert items, bars indicate percentages where all percentages are on the basis of the total number of respondents (66). Consequently, the sum of the stacked bars for one Likert item do not necessarily sum up to 100%. This is particularly the case for all questions broken down by activities, since any one participant was only asked in more detail about two activities for current practices and one in the context of CAPUSH to keep the length of the survey manageable.

Free text responses were first categorised and classified by associating codes in a spreadsheet. For each question, we extracted keywords or tendencies such as “positive/negative”, “manipulation”, “quality”, “privacy”. We then used these keywords to group the corresponding answers and refine the keywords. For those text answers referring to two or more keyword groups, we simply copied them to the corresponding groups.

# 5 FINDINGS

We report our findings in the same order as we formulated our research questions: (1) we describe participants’ current practices and the tools they use to capture across diverse activities; (2) we detail how participants perceived and reported on the different features of the design concept through the lens of our framework; (3) we compile issues and concerns reported by respondents.
## 5.1 RQ1: Current Capturing Practices

<figure><img src="image_12.png" /><figcaption>Fig. 4. Current practices in capturing content from fabrication activities
$n(3dprinting)=28, n(lasercutting)=25, n(CNC)=19, n(electronics)=19, n(woodworking)=13$</figcaption></figure>

Our data confirm that almost all respondents use their **personal devices** such as smartphones or digital cameras, sometimes with tripods, to capture content as shown on Figure 4a (How). They also confirm that **pictures** and **videos** play an important role when capturing content (What): Figure 4b shows that pictures are the most common capture format, followed by video across most activities. Respondents frequently save **files** as well and rather homogeneously across activities. For some activities, like woodworking or electronics, **sketches** are also somewhat frequent to keep, for instance, components and connections of electronic circuits ("another easy and simple way to record and showcase the kinds of circuits I'm building" - p8).

Only few respondents indicate that they are not used to capture anything to show the result (after the activity) Figure 4d. When asked if they are used to capture the process (during the activity), opinions diverge and depend much more on the actual activity. Those doing woodworking and CNC mostly are for capturing the process whereas respondents disagree on this for electronics, laser cutting and 3D printing. For instance, P15 takes pictures during 3D printing "For documentation and communication and to keep track of the print's quality", p62 takes pictures of all details involved in the woodworking process: "pieces, cut pieces, pre-assembly, during glue up, clamp down, any mistakes made throughout the process, assembled piece before and after sanding and sealing".

In general, capturing images (pictures) appears more appropriate **after** the activity, for instance to "record good samples or defect" - p27 or to remember the montage in the case of electronics "easiest means to record constructed circuits using physical components and breadboards" - p8. In contrast, video capture appears more appropriate **during** the activity to record the process of e.g., 3D printing, laser-cutting or CNC (10 of 16 respondents). For instance, "this is to show what happens in real time to others who want to know what 3D printing is like in real time (not static)" - p8. When
taking pictures during the activity, the purpose is then to keep track, record the iterations, and the methods as well as a mean for remembering the settings used.

<figure><img src="image_13.png" /><figcaption>Fig. 5. Frequency of help solicited by respondents to capture images and videos.</figcaption></figure>

Most respondents do not ask for help when they need to take a picture or record a video as shown in (Figure 5), however 23 of them gave examples of situations when capturing might be difficult. For instance, they may want to change the perspective to appear on the camera but cannot because their hands are busy and/or dirty. They also complained about the resolution of their devices or issues of the workshop environment such as bad lighting (e.g., protective glass reflecting the light on the machines), heat and wood chips, machines noises, vibrations and the need to protect the cameras against dirt. Some of them regretted that they did not have enough skills to capture nice content with nice angles. Finally, they mentioned forgetting to capture because of the switch between capturing and fabrication.

## 5.2 RQ2: Exploration of Framework Dimensions Through CAPUSH

We now present the results relating to the ways in which respondents would imagine using CAPUSH to capture images and videos, and how it could influence their current practices. The results are organised according to the dimensions of our framework.

**Why to capture.** The survey did not contain a question asking explicitly about the reasons and motivations to create knowledge resources and if those would change with a system based on CAPUSH. However, some respondents spontaneously commented about them, sometimes raising emerging opportunities. For instance, at the organisational level, respondents (including 3 managers), mentioned that CAPUSH could be used for safety and management purposes, providing "Emergency Stop in case of fabrication problems. Give an advice when the part is fully processed. Send a message when the process is done" - p19. P52 mentioned that it "could be useful for safety purposes. For example showing machines unattended, safety guards not in operation". 4 respondents would use it to keep track of the visits, automatically identifying visitors, "or presenting analytic data on the use of the machines or the occupation level of the space" - p33. P11 also envisioned to locally showcase the captured content from different projects "[...] to teach others using the space and to inspire artists working at our lab" - p11.

Five respondents suggested potential benefits at the individual and community levels. Benefits include: automating content creation for diffusion to generate newsletters; making short summaries or accelerated video compilations (p19, p33 & p49); automatically send content to a wiki; "to enable keeping track" - p9 or to "automatically save pictures with machine setups in the wiki were we can add a comment" - p14.

**What is captured.** Most respondents would take pictures with CAPUSH for different kinds of activities as summarized in Figure 6a. Video capture (Figure 6b) is "more suitable for some steps of the projects" - p43, "all of our actions would be recorded" - p6. Interestingly, 11 of the 12 respondents who considered CAPUSH for the activity "electronic" 6 would record videos with CAPUSH, which

<footnote n="6">⁶The survey software selected the two activities for which participants indicated capturing most frequently pictures or videos. Questions on current practices were asked for both activities, whereas exploration of CAPUSH was centered on the</footnote>
<figure><img src="image_14.png" /><figcaption>(a) Reported likelihoods of taking pictures for different (b) Reported likelihoods of recording video for different types of activities.</figcaption></figure>

<caption>Fig. 6. Reported likelihoods of taking pictures and recording videos with CAPUSH depending on type of activity
$n(3D printing)=16, n(laser cutting)=11, n(electronics)=12, n(CNC)=6, n(woodworking)=10$</caption>

was not the case when asked about their current practices (Figure 4b). Some respondents anticipate extending the kind of content they usually capture thanks to CAPUSH (p21 & p24): “I think I would take timelapse videos of all my builds, if that would be very easy to do (only little time needed for setup etc)” - p21. Finally, respondents appreciated the possibility to associate meta-data (contextual information, tags) as illustrated in Figure 7 to simplify the organisation, the retrieval and the reuse of the content: “By typing the tag it would be easy to retrieve other projects using the same techniques, and eventually to find other strategies, also this would allow to retrieve one’s own work and to fill the wiki without searching/transferring all programs and pictures” - p9. “Having tags autoformatted would be terrific. It would also help me prove who created what” - p20.

Because respondents perceived CAPUSH as undemanding and readily available, they envisioned capturing content more frequently: “If the system was set up and I used it, it would be much easier to capture [...] and I would probably take more photos” - p36. CAPUSH also offers “more flexibility” - p16 to capture enabling better quality and richer content: “[It’s] a maker’s dream, it enables several angles and cameras attached at strategic places to create a beautiful montage of the creative process!” - p3. Two respondents also imagined to extend capture to non-physical activities by recording the computer’s screens with OBS<fnref n="7" />.

<figure><img src="image_15.png" /><figcaption>Fig. 7. Reported usefulness for the 4 types of tags suggested: customs, tool/machine, location in the workshop, and date. n=66</figcaption></figure>

<footnote>first main activity. Consequently, out of the 49 people who indicated doing electronics (as shown in Figure 3), 19 where queried on their current habits regarding electronics (as shown in Figure 4) and only 12 were queried how CAPUSH could be used to capture an electronics activity.</footnote>

<footnote n="7">⁷Open Broadcaster Software https://obsproject.com/fr</footnote>
<figure><img src="image_16.png" /><figcaption>Fig. 8. Capture and retrieval better than current.
$n=66$</figcaption></figure>

**How to capture.** A clear majority of respondents appreciated the concept of CAPUSH to capture content (see Figure 8) and rated it as better than what they are currently using both concerning capturing itself and retrieving content from a shared repository. In particular, they appreciated not to have to use their own device and risk to break them: “I don’t have space on me to carry a phone all the time; I don’t want to damage my own camera; it might be a good reminder to take process pictures” - p62. However, other respondents also wished for openness, to be able to continue to use their personal devices and software tools together with CAPUSH. P42 wanted to be able to connect the system they currently use in their workshop.

Similarly, p27 & p61 would like to use their smartphone or GoPros to take pictures with CAPUSH through an app.

Concerning the variety of unit types, respondents showed a clear preference for both the fixed and the clamp camera over the head-mounted camera and the table bot (see Figure 9) suggesting that more complex unit types may not be necessary and that mobility and hands-free operation may be the decisive properties: “we have several small rooms and a lot of machines, mobile cameras are useful” - p24 although at least one respondent worried that the multiple mobile cameras such as the clamps would be cumbersome: “it is annoying and you have to think of as many clamps as there are places where you want to attach it” - p31. Finally, respondents seemed to appreciate the opportunity for hands-free manipulation given by the units, as P18 commented about the table-bot: “I can imagine the use of such a device in the case of experimentations where the practitioner has both hands busy” - p18. About the head-mounted camera, P8 commented: “handy, a bit invasive, but totally useful so I can continue to use my hands and still record all my work” - p8. Freeing up one’s hands might as well help makers to better focus on their work (p47).

<figure><img src="image_17.png" /><figcaption>Fig. 9. Reported appreciation of the camera units of CAPUSH.
$n=66$</figcaption></figure>

**When to capture.** Respondents expressed a similar intent to capture more during (process) as well as after (result) the activity indicating that they expect the pure presence of capturing units to
<figure><img src="image_18.png" /><figcaption>(a) Reported likelihood to capture process with CA- (b) Reported likelihood to capture the result with CA-PUSH PUSH</figcaption></figure>

<caption>Fig. 10. Reported likelihood to capture the process and the result with CAPUSH for activities where n>5
$n(3dprinting)=16, n(lasercutting)=11, n(CNC)=6, n(electronics)=12, n(woodworking)=10$.</caption>

remind them to take pictures and videos and more generally to think about documenting their work.

“It might be a good reminder to take process pictures” - p62. As Figure 10a and Figure 10b illustrate, this is especially the case for activities involving the use of tools. In addition, three respondents mentioned the advantage of a community capturing system across the lifetime of a project.

“It would help me replicate my initial actions for future builds that need the same process it would be useful to have more information available to create a more effective narrative of what I did, when I did it, and how it would help others trying to replicate what I’m doing (if they are so interested)” - p8.

**Where to capture.** A fixed camera on machines was one of the preferred units because it is “useful” or “interesting” (7 respondents). 6 other respondents appreciated that it requires no effort to set up since it is already installed and that it would consequently make it easier and faster to record content from a machine. In particular, they mentioned that they would essentially capture videos or make timelapses of processes and manipulations: “it has the advantage of similar images from different stages” - p39.

Respondents also appreciated the clamp camera to position it in the environment and to adapt it to the scene: “it’s possible to attach it anywhere, good idea” - p9, giving examples of the case of “manual activities” - p14 or “activities where a fixed camera is not suitable” - p10. “It can create a multitude of angles to create interessant point of views” - p3.

The Table bot received mixed opinions because it seems unsuitable on cluttered desks and would require to free space, resulting in less spontaneity when capturing content. Some respondents also feared that the robot would get in the way of the primary activity and cause distraction. “I don’t want additional stuff on the work table, only gets in my way” - p21. P15 was more positive but would prefer an approach using “a linear frame with a rotating head looking down toward the table”.

The head-mounted camera that makers wear (person) also received rather mixed opinions. On the positive side, some respondents appreciated that it offers a first person point of view and the possibility to free both hands while capturing. “This is probably the best way to capture what I am doing right in front my workbench/work surface” - p8. On the flip side, 15 respondents expressed concerns in their comments. A camera carried on the head might cause discomfort and, importantly, be incompatible with head-worn security equipment. Additionally, it would require special care and attention to avoid moving shots and blurry pictures which would result in extra work to remove them afterwards. It would “move too much” - p42, “make [me] seasick” - p9, and “require additional work to remove useless moving shots” - p24.
<figure><img src="image_19.png" /><figcaption>Fig. 11. Appreciation of the manual control vs. automated control of the camera orientation.

$n=66$</figcaption></figure>

**Who captures.** Respondents tend to prefer the automated control of the camera orientation to the manual one with a joystick (see Figure 11). However, some respondents questioned the technical feasibility and reliability due to lighting, imagining a final result with possible “unstable videos” - p38 or “confusing shots” - p17.

In contrast, the joystick to manually control the camera orientation was perceived as “useless”, “too complicated” or “cumbersome”. Two respondents would rather move the camera with their hand directly: “we are not in a James Bond movie” - p31.

Regarding the automatic control of a camera's position, respondents questioned the feasibility of programming a table bot capable to deal with a cluttered desk (see Where). The autonomous locomotion might as well contribute to distraction as noticed by 4 respondents.

The way to trigger video/picture captures was not described in the concepts' presentation. However, two respondents (p10 & p25) spontaneously commented on the interest of adding an automatic trigger or offering an alert system to suggest to capture (p25) or trigger the capture via voice-command: “start tracking”, “take a picture” - p4.

The concept includes to automatically upload the content captured from the different units to a local repository. Respondents indicated that this approach would be useful and save time (p17 & p42) because uploading and managing content is “tedious”: “Getting the content from the phone to a useful place often doesn't happen” - p56, “Very useful for keeping stuff together and allowing ease of access” - p10. Nonetheless, some respondents did not find this approach essential and questioned how to manage access rights: “This can be useful or misused according to who is working with it. We had problems in one makerspace with the camera's, that led to a lot of power-gaming/headgames” - p35. “It will be useful but I wonder it could be more useful than Google photo” - p27.

The different contextual tags would help to retrieve and easily reuse the content (see What), but tagging all content can require a very good organisation and be cumbersome. “I'm too lazy to set them manually on my phone, makes it hard to find photos again” - p21. Providing automatic capture of meta-data as tags, including the location in the workshop, the machine and tools detected in the stream and timestamps, might solve this issue and was well received by respondents. “Automatic tags are awesome” - p21. “With the automatic tags, will save me time of doing it later in the computer and try to remember the details” - p48

## 5.3 RQ3: Potential Issues and Concerns

While a large majority of respondents would want a CAPUSH system deployed in their workshop (Figure 13 and Figure 8), some respondents raised important concerns that any implementation of camera-based capturing systems in fabrication workshops should take into account.

**Privacy.** Some respondents suggested that consent from users of the workshop for being filmed should be explicitly gathered because some persons might feel uncomfortable (p13 & p16) or do not
<figure><img src="image_20.png" /><figcaption>Fig. 12. Appreciation of a shared local repository with tags.
n=66</figcaption></figure>

<figure><img src="image_21.png" /><figcaption>Fig. 13. Appreciation of the overall system.
n=66</figcaption></figure>

want to be filmed without knowing it (p44, p21, p34, p39 & p25): "In case camera would capture other persons in the background, it would be hard to use, as some people strongly dislike the use of cameras at our fablab" - p21. "Maker-spaces know failure, meaning something can go wrong, even badly wrong. Simple mistakes can turn projects into smoke. This is something you don't want to document on a personal record. If there are only friends, fine, but if there are others not friendly, bullying is an issue that should be avoided. A class situation [sic], where the attendance is not strictly voluntarily, could be awful once lesser skilled attendants turn their attention to these devices to tinker with them instead of paying attention." - p39. "Part of the young people who come here are not comfortable with their self-image. I know that it would cause problems for some of them if they happened to be on videos, and maybe that the sole presence of cameras would make them uncomfortable" - p16. Some respondents suggested that some spaces should remain entirely free of cameras (p10, p50 & p56).

**Intellectual property.** Respondents recommended to pay attention to intellectual property in the context of company projects (p20, p23, p62), artists rights (p52), theft (p11), or industry equipment (p63) because it might prevent the use of cameras if not strictly framed. A few mentioned there could be problems in the cases where makers do secret projects (p27), adult content (p26), or illegal content (p33). "I'm concern about intellectual property when all files are shared by others especially when it's businesses/companies/studios that operate out of a shared space, to have their property be easily viewed by others." - p62. "Not everyone want to shared their projects, for example if they are purposely on the fringes of legality" - p33.

**Safety.** Some respondents questioned the safety of the CAPUSH concept because the workshop is already full of machines (p37): "Most of the options are based around devices that would get in the way of performing the activities, so are inherently unsafe, as any attention paid to the use of a camera is attention that is not being used indirectly for the activity, which is a bad way to operate when you are working with dangerous tools/materials." - p35.
# 6 STUDY LIMITATIONS

The findings reported in this article stem from an online survey evaluation based on a design concept introduced through a video. This approach has the advantage of facilitating the exploration of a diverse set of different units with various properties. An in-person evaluation using prototypes of these unit types runs the risk of participants focusing on smaller usability issues (depth first evaluation) instead of the breadth of unit types and how each of these may or may not be a suitable *approach* to capture content [29, 67]. However, the approach also has limitations. Most notably, our approach is not suitable to explore how actually *using* a unit would *feel* like. This concerns in particular the head-worn unit. Nonetheless, participants who indicated in our study that they would *not* want to use it, would likely also *not* be willing to try it out if they had the choice between different unit types in an in-person study. Another limitation is that each respondent likely imagined details not made explicit in the video in a different way which may have increased noise in our data. While the approach enabled us to collect rich data to inform future research directions, an in-person study will still be necessary to validate how people's impressions and expectations (reported in this article) compare with their actual behavior when they are able to use a real system during their fabrication activities, ideally in the form of a field study and taking into account the insights gained from the reported study. Another limitation of our study is that while we aimed in our recruiting strategy for a diverse international sample and received responses from 25 different countries, a few countries are disproportionately over-represented (as shown in Figure 3). This is unlikely to be a threat to validity, but it is possible that a larger, representative sample of the global fabrication workshop community may have been able to uncover additional risks and opportunities.

# 7 DISCUSSION AND OPPORTUNITIES FOR DESIGN

We revisit now the three dimensions of the design space explored through CAPUSH and the survey study: “Multiplicity and variety of capture units” and “degree of automation” before discussing privacy and ethics, two dimensions that emerged from our study.

## 7.1 Multiplicity and Variety of the Capturing Units

Our study explored how multiple and varied units could support the diverse and distributed nature of capturing activities. Regarding multiplicity, results suggest that this is indeed essential, as fabrication activities are distributed, and more available capture devices increase the opportunities for capturing content in various ways. Concerning variety, results are less straightforward. However, what we see as a new opportunity, is the ability to integrate makers’ personal capture devices (e.g. smartphones) into CAPUSH to leverage the unique aspects they bring.

*Multiplicity Increases Capture Opportunities.* The fact that there are multiple cameras increases capture opportunities, for several reasons. First, because ubiquitous cameras serve the purpose of acting as a reminder. This can mitigate one of the main barriers reported in literature [77, 82] and confirmed by respondents in our study, which is that capturing is difficult and often forgotten, as makers focus on tasks that are physical and often cognitively demanding. Beyond capturing more content during a project, more units support keeping track of the process of fabricating an artifact (P62, P9), reinforce re-usability (P14) and create better narratives (P3). This observation is in line with Gourlet et al. [28] who suggest that modularity is important when collecting traces of different activities at different stages of a process and Keune et al. [36] who encourage the salience of capturing devices meant for documentation. Second, because more capture units mean there are more angles and more locations (even inside machines) that are ready to be recorded without overhead. This facilitates capturing different perspectives simultaneously on the same artefact,
which provides richer visual content for knowledge resources [21].

*Limited Variety seems Sufficient.* Many makers were skeptical about the usefulness of more complex unit types, that is, the head-mounted camera and the table bot, and feared they would be distracting or simply get in the way. At the same time they appreciated for fixed cameras the simplicity (no setting up) and predictability of footage (always the exact same viewpoint (P39)) and for clamp cameras their flexibility (freely adjustable viewpoints (P3)). Thus, given our findings, these two unit types seem complementary and sufficient. There may be some need though for temporary contraptions to attach to units, for example, to protect a unit from dust or debris spit out by a machine (P62), or to adjust exposure levels to record special activities like welding.

*Personal Device Integration.* In our framework analysis, we observed that personal devices (e.g., smartphones) are appreciated because they are readily available and familiar to the maker, something our study confirms.

While most respondents expressed support for adding a community shared capturing system to their workshop, some asked explicitly to keep such a system open to use other types of capturing devices, such as their smartphones or Gopro cameras, but such that the captured footage is treated in the same way, that is, added to the repository and enriched with contextual meta-data. This gives makers the ability to combine properties they value from CAPUSH with specific capture requirements they may need (e.g. macro zoom, timelapse or Snapchat filters). Beyond camera-based units, integration can also happen with other forms of content capture, such as screenshots (P33) or sketches, which participants highlighted as relevant (Figure 4b). Ideally, makers should be able to include any content type together with the picture and video content captured with CAPUSH.

*Opportunities for Design.* Capture systems should consider multiple cameras distributed in space and enable straightforward integration of makers’ own capturing devices for leveraging their unique capture capabilities. The main challenge is to reduce the required overhead (favor simplicity) and facilitate predictability of the outcome. Makers also produce other content types, besides pictures and videos, and some expressed interest to send everything to the same repository.

## 7.2 Degree of automation: Mixed-Initiative Content Capture

As expected, opinions and preferences diverged across participants when it came to delegating control. Balancing automatic and manual control is indeed challenging, specifically in maker spaces: Previous work already noted that automatic capture control generates a lot of data without certainty of what is being captured [36], while complete manual control can require too much of the maker’s attention distracting them from the main task of making. We posit that delegating control in capturing systems does not necessarily need to be all or nothing, but could follow a mixed-initiative approach aiming to maximize the benefits of both types of control [3]. In mixed-initiative control, the system and user both contribute to a task (in this case, controlling and parameterizing the capture system) in a flexible way, as they can delegate and take control as the task advances in order to contribute what each does best. Our study elicited considerations for delegating control to capturing systems. We discuss these considerations regarding mixed-initiative: task interference and customization granularity.

*Task Interference.* Automation can introduce unintended extraneous interference to the activity and output. We observe reluctance for automation due to the uncertainty of resulting behavior and output. We believe that this can be mitigated by setting restrictions on automation. For instance, P15 suggested constraining locomotion of the tablebot to one dimension ($T_x$) instead of two ($T_{xy}$), while controlling when capture takes place. This alleviates the maker from remembering to move the unit, with a mix of control that mitigates potential interruptions of the activity as the maker can more easily predict the unit’s behavior (which parts of the workbench the camera can invade by
potentially rolling over material), as well as output volume (keeping control of the amount of media generated). Another example is that automatic orientation was perceived as a potential source for unsteady shots (p38), but it could be interesting to explore in more detail if being able to control sub-parameters (e.g. movement speed) would lead to more certainty of output. Lastly, interference introduced by automation is likely specific to a given task, and therefore systems cannot assume that one type of automation (e.g. unit movement) will necessarily interfere with work always in a given way.

*Customization granularity.* Customization at different degrees of granularity supports a varying level of experience and preferences. As capture systems grow in complexity, more and more elements will be available for control, including movement, orientation and position, as well as the moment of capture. We observe that makers’ needs and preferences play an important role in composing the right mix. Previous work studying how people manage personal media has identified this [79], for example, if a person’s career depends on these media, manual control is desired as the cognitive cost of capturing is outshined by the benefits of making sure the media will not be lost. To lower the complexity, capture systems could provide mixed-initiative customization assistance (MICA) [10] to help makers navigate through complex customization highly-granular options. Finally, we believe that reminding the user to exert manual control might be a better strategy than fully exercising control, for example by having the system provide recommendations on when to act (e.g. when to trigger capture).

***Opportunities for Design.*** Capture systems could let makers set constraints for automation *before* starting the activity, so that makers delegate control *during* the activity to the system in the way they want. Awareness of these parameters is key, *before* starting the task regarding what can be controlled and what will be the effects of setting parameters, helping users set their desired preferences. *During* the activity, systems should give feedback of automated parameters (e.g., blue color on the wheels that are controlled automatically) and when triggering capturing (e.g., sound), both for the maker that set the parameters so that they do not forget, but also for other makers who might occupy a part of the fablab where the system is running. At the same time, feedforward is also promising to indicate which areas a device can occupy as it moves, and what areas are in its capture reach given the selected set of automation, increasing predictability of output.

## 7.3 Social Context: Privacy and Ethics

Fabrication workshops have been already identified as socio-technical environments [33, 69], as cultures of making “*shape collaboration and the social organization of work*” [59]. We argue that content capture, and thus knowledge production, can support and contribute to the construction of social activities. First, as resources for care practices that reflect makers’ ethics. Toombs et al. [70] discuss the ethics of makers as a complex negotiation of a neo-libertarian ethos and care ethos. Captured content supports care practices both overt-explicit (e.g. helping others become more independent through sharing how a process is done correctly) and overt-implicit (e.g. increasing safety through content capture to monitor safe machine operation). Content can also help makers accrue social capital, through proof of activities and achievements, which contributes to the notion of the “self-made” ethos in the maker space. Second, for entrepreneurship. Hui et al. [33] discuss how physical, technological and online resources are leveraged to promote values associated with this goal, and help makers walk a path towards it. Thus, content can be used for cognitive apprenticeship—learning a task by observing expert behavior [18]—by creating new opportunities and increasing reach to more apprentices. Also, it enables apprenticeship to take place offline: content can be made available on demand increasing the chances of watching experts work, as
doing so by standing next to the expert is limited by scheduling and the available space in the workshop.

Despite contributing to social practices, content capture can have implications on privacy and ethics, potentially posing a threat to others’ intellectual property. Our study elicits how not only a system can unintendedly capture another person and their work without consent, but that the mere presence of the camera can put other makers in an awkward position of avoiding certain areas or avoiding conversations out of fear of being recorded. This is important as intellectual property is a major concern for makers, and can be an extra barrier in documenting [82], and hacker ethics vary widely, from radical activists [65], to seeking peace through technology democratization [43]. Responses indeed showed that the variety of people occupying the space have unique values and perceptions that nuance the concerns. We thus believe that capture and privacy are a relationship rather than a consequence, as they relate to factors such as the degree of acquaintance with the person being captured and the capture, the self-image of the captured person, or the level of choice a maker has (e.g. mandatory class attendance).

***Opportunities for Design.*** By considering privacy and ethics, a capture system can contribute to social practices in fabrication workshops. We believe that ensuring visibility of on-going capturing activities and giving people control are two key aspects in a capture systems that makers can use to tackle privacy. Regarding visibility, simple mechanisms such as a glow aura or line lasers showing the area captured provides others with awareness. In doing so, others can modify their behaviour to satisfy their needs and values regarding privacy for their ongoing activities. Moreover, a maker capturing content could be able to control the depth of a captured area, for example by setting the capture depth to a certain level (e.g., no more than 1 meter) by relying on depth sensor information and blurring all areas considered background, or for cameras capable of setting a very narrow depth focus by simply setting it such that the foreground is in focus while blurring the background. More advanced mechanisms can provide finer control, such as blurring faces automatically if other makers walk into the frame. These measures are not exclusive, as the capture area can be exposed, limited, and still modified ex-post in case of unexpected appearances. Overall, while no one of our participants brought this up, moving from personal devices—which are omnipresent and for which a bystander generally cannot know if they are currently recording—to a shared community camera system could present an opportunity to develop systems which are respectful of privacy and put awareness and limitations in place to respect everybody’s personal choices.

# 8 PROOF OF CONCEPT IMPLEMENTATIONS

There are many different ways to reify the CAPUSH design concept into functional prototypes. Overall, the specific choices heavily depend on one’s principles and constraints: For example, for maker spaces with extremely limited resources it might be important to find a frugal solution; others might value ecologically responsible choices most and may want to upcycle otherwise obsolete materials; other places might consider capture quality as the most important property.

For our own proof of concept implementations<fnref n="8" />, our guiding decision criterion was that the used material should be rather *low cost and easily available* to a large range of different maker spaces, even if only modest resources are at hand. We implemented proof-of-concept prototypes for the fixed, pan-tilt, clamp, and table bot concepts to explore the feasibility of the desired functionality and of our design concept overall. All our prototypes are based on Raspberry PI boards as they have a small form factor and are often readily available in fabrication workshops. Table 3 provides a summary of how we implemented various features of CAPUSH and limitations we observed.

<footnote n="8">⁸Bill of material and current state of implementation are available on https://af-fab-le.github.io/capush</footnote>
<table><caption>Table 3. Overview of our proof of concept implementations sorted by feature.</caption><thead><tr><td>Feature</td><td>Description</td><td>Implementation</td><td>Limitations of our approach</td><td>Units types</td></tr></thead><tbody><tr><td>Networked camera</td><td>Camera accessible via local wifi</td><td>Raspberry Pi3b+ w/ camera module V2</td><td>Size of the Raspberry PI reduces easy manipulation + alternatives exist</td><td>all</td></tr><tr><td>Mobility</td><td>Portable power supply</td><td>RPi UPSPack V3</td><td>Limited autonomy</td><td>Clamp camera</td></tr><tr><td>Pan/tilt assembly</td><td>Mechanism to adjust the camera viewpoint</td><td>Pan/tilt frame with 2 SG90 servos</td><td>Active servos limit manual manipulation while active</td><td>Pan-tilt camera, clamp camera, table bot, (head-mounted camera)</td></tr><tr><td>Clamp</td><td>Attachment mechanism</td><td>clamps with strong springs and a hole to attach a unit</td><td>Opening and spring strength limit where it can be attached</td><td>Clamp camera</td></tr><tr><td>Locomotion</td><td>Robotic base to enable locomotion</td><td>Alphabot V2</td><td>Low camera viewpoint, limited autonomy</td><td>Table bot</td></tr><tr><td>Tool tracking</td><td>Cameras follows a tool or object around</td><td>Color tracking with OpenCV + colored dot on tool</td><td>Marker needs to remain in frame; requires constant lighting</td><td>all with pan/tilt assembly</td></tr><tr><td>Location recognition</td><td>Cameras localize themselves</td><td>Fiducial markers associated to location or machine</td><td>Sufficiently sized fiducials required throughout the space</td><td>Clamp, head-mounted camera, table bot</td></tr></tbody></table>

In principle, any camera accessible via network could be used as a fixed camera unit. For example, upcycling otherwise obsolete smartphone models or the use of GoPro cameras would result in higher quality footage than the above approach. The concrete choice affects, however, the extendability of the unit type: extensions based on GoPro or smartphones are likely limited to physical appendages permitting to attach it in various places whereas units built on top of a microcontroller provide more avenues for new features or the automation of features. A property which can be automated and which we explored in our study is view point control. Both manual and automatic control require some form of user interface though to indicate where the camera should point or tell an automated control what to keep in the field of view. Depending on the level of indirection [8] and the desired automation, different control interfaces are possible, much of which have already been explored in previous work for both manual [25] and mixed control [6]. With our proof-of-concept prototype, we tested a basic implementation of the automatic tracking mode mentioned in the study and the video shown to respondents. It is based on color detection using OpenCV<fnref n="9" /> which enables tool tracking as long as a colored dot is attached to the tool and visible in the camera image. More advanced tracking, including tool detection based on the appearance of the tool, is beyond the aims of our proof-of-concept but might be feasible based on results from previous work [14].

A major concern with automatic viewpoint control is that the camera image may move excessively and thus require some mechanism to stabilize the image which can be done programmatically (e.g., [6]) or through a physical stabilizer unit. Unstable footage is also one of the reasons for which we did not realize a prototype for the head-mounted unit type. Previous work already explored capturing using head-worn Google glass and observed that the resulting footage risks being unstable and of low quality [15]. Thus, an image stabilizer unit, such as a gimbal pan/tilt unit,

<footnote n="9">⁹https:// opencv.org/</footnote>
would be necessary to address the issue and achieve smooth footage. A usable prototype combining these features would require a high degree of miniaturization to be portable on one's head so as to not disturb makers while working on their projects. While this is a promising avenue for future work, realizing such a prototype goes beyond the scope of our proof of concept implementations which focused on exploring low cost implementations based on easily available material.

# 9 PERSPECTIVES

Our empirical findings show promising research directions to extend our framework and design concept along their six dimensions.

**Why.** Content capture for organisational benefits has received less attention than for individual and community goals, and thus constitutes a promising research direction. Respondents in our study spontaneously described the interest of CAPUSH for contributing to workshop management, for instance, by giving managers access to camera feeds from machines for security or maintenance purposes. Future research can explore how the design concept of CAPUSH could be extended to these purposes, in particular, how to give access to managers, while respecting makers' privacy (as discussed in subsection 7.3).

**What.** The framework and concept can be extended regarding *What* content is captured, by considering other kinds, including (1) the output of non-physical activities (e.g., programming or designing) that are not covered by CAPUSH, such as code files, CAD files or sketches; and, (2) the parameters of machines and tools (e.g., Gcode), which could be saved and associated with the captured content. These two types are not currently included in the list of values for the *What* dimension of our framework.

**How.** As we mention in the discussion subsection 7.1, designing systems that can integrate dedicated capture devices with existing ones would enable makers to also use equipment that they own and master. It is also possible to include contraptions which provide some of the functionality of a CAPUSH unit but with personal devices, for example, a clamp with a flexible arm which could either hold a mobile unit or makers' own devices. The combination of a clamp and a flexible arm would enable more precise *manual* control over camera viewpoints but with makers' own devices. Considering adding more degrees of freedom to the orientation (yaw) could also be made possible with more complex devices than just a pan/tilt, and could be interesting in some cases, for example, when the camera is above or attached at an angle. Moreover, integrations with existing devices can provide *control* over units.

Camera units can be used to control devices, for example, pointing with one's smartphone camera to a camera fixed on a machine can trigger a snapshot from the latter, as well as capturing the state of the machine, or pointing at a computer screen can start video screen recording on the computer itself. Such functionality would of course need to be carefully tested for their potential to be exploited in violation of others' privacy and may not be suitable for all kinds of fabrication workshops.

**When.** Various types of content could be relevant to be captured before the project starts, such as source material like pre-existing documentations which inspire a new project or from which parts are reused for a new project, or mockups and paper or video prototypes which could be captured using CAPUSH units.

**Where.** The scope of our framework and concept is the context of a fabrication workshop. However it is interesting to reflect on the possibilities such a concept could generate outside the workshop as well. Using CAPUSH across different fabrication workshops, by using similar units, fabrication grammars [68] and machine grammars [73], could enable to share and collaborate with different places, following the idea of Troxler et al. [74] with FabML.
**Who.** We discuss in subsection 7.2 about the mix-controlled approach to the features of the units. The control can be done manually by the maker, or automated and performed by the system. Our framework could be extended by considering not only the maker and the system, but also a third person in charge to partially or totally controlling some aspects of the capture (e.g. configuration, trigger, position or orientation). This person could be a manager inside the fabrication workshop, or a maker at home to follow the activity of a peer and collaborate. We can also see some opportunities due to the Sars-Cov2 pandemic which saw most fabrication workshops closed for extended periods and large parts of the population constraint to their homes. Instructors who taught hands-on activities during this period were interviewed by Labrie et al. [42] and reported having difficulties to verbally indicate to the students to move the camera such as showing a part of the physical objects. We can imagine extending our design concept with connected units that could broadcast the stream of the different students of the class to the instructor, and provide her with remote control access of the orientation or position of the cameras to enable a better vision on the progress of students in real time.

## ACKNOWLEDGMENTS

We thank all the participants of this study for their valuable time as well as the HCI Sorbonne team and the Sorbonne Université Fablab for helping with this research. This work was supported by a grant from Agence Nationale de la Recherche (ANR-17-CE33-0001).

## REFERENCES

[1] Maneesh Agrawala, Doantam Phan, Julie Heiser, John Haymaker, Jeff Klingner, Pat Hanrahan, and Barbara Tversky. 2003. Designing effective step-by-step assembly instructions. *ACM Transactions on Graphics (TOG)* 22, 3 (2003), 828–837.

[2] Shinya Aizu and Koji Tsukada. 2018. Support System for Creating Manufacturing Manual using Smartwatches. In *Proceedings of the 2018 ACM International Joint Conference and 2018 International Symposium on Pervasive and Ubiquitous Computing and Wearable Computers*. ACM, Singapore Singapore, 323–326. https://doi.org/10.1145/3267305.3267593

[3] J. E. Allen, C. I. Guinn, and E. Horvtz. 1999. Mixed-initiative interaction. *IEEE Intelligent Systems and their Applications* 14, 5 (Sept. 1999), 14–23. https://doi.org/10.1109/5254.796083

[4] Gunnar Almevik, Patrik Jarefjäll, and Otto Samuelsson. 2013. Tacit Record: Augmented Documentation Methods to Access Traditional Blacksmith Skills. In *Beyond Control – The Collaborative Museum and its Challenges. International Conference on Design and Digital Heritage (NODEM’13)*. Interactive Institute Swedish ICT, Stockholm, Sweden, 143–160.

[5] Michelle Annett, Tovi Grossman, Daniel Wigdor, and George Fitzmaurice. 2019. Exploring and Understanding the Role of Workshop Environments in Personal Fabrication Processes. *ACM Transactions on Computer-Human Interaction* 26, 2 (March 2019), 1–43. https://doi.org/10.1145/3301420

[6] Ignacio Avellino, Gilles Bailly, Mario Arico, Guillaume Morel, and Geoffroy Canlorbe. 2020. Multimodal and Mixed Control of Robotic Endoscopes. In *Proceedings of the 2020 CHI Conference on Human Factors in Computing Systems (CHI ’20)*. Association for Computing Machinery, Honolulu, HI, USA, 1–14. https://doi.org/10.1145/3313831.3376795

[7] Matthias Baldauf, Schahram Dustdar, and Florian Rosenberg. 2007. A survey on context-aware systems. *International Journal of Ad Hoc and Ubiquitous Computing* 2, 4 (2007), 263–277.

[8] Michel Beaudouin-Lafon. 2000. Instrumental Interaction: An Interaction Model for Designing Post-WIMP User Interfaces. In *Proceedings of the SIGCHI Conference on Human Factors in Computing Systems* (The Hague, The Netherlands) (CHI ’00). Association for Computing Machinery, New York, NY, USA, 446–453. https://doi.org/10.1145/332040.332473

[9] Ronald Bledow, Bernd Carette, Jana Kühnel, and Diana Bister. 2017. Learning from others’ failures: The effectiveness of failure stories for managerial learning. *Academy of Management Learning & Education* 16, 1 (2017), 39–53.

[10] Andrea Bunt, Cristina Conati, and Joanna McGrenere. 2007. Supporting Interface Customization Using a Mixed-Initiative Approach. In *Proceedings of the 12th International Conference on Intelligent User Interfaces (Honolulu, Hawaii, USA) (IUI ’07)*. Association for Computing Machinery, New York, NY, USA, 92–101. https://doi.org/10.1145/1216295.1216317

[11] Glenda Amayo Caldwell and Marcus Foth. 2014. DIY media architecture: open and participatory approaches to community engagement. In *Proceedings of the 2nd Media Architecture Biennale Conference on World Cities - MAB ’14*. ACM Press, Aarhus, Denmark, 1–10. https://doi.org/10.1145/2682884.2682893
[12] Tim Campbell, Jonathan Harper, Bjorn Hartmann, and Eric Paulos. 2015. *Towards Digital Apprenticeship: Wearable Activity Recognition in the Workshop Setting*. Technical Report UCB/EECS-2015-172. Electrical Engineering and Computer Sciences, University of California at Berkeley. 7 pages.

[13] Scott Carter, Matthew Cooper, John Adcock, and Stacy Branham. 2014. Tools to support expository video capture and access. *Education and Information Technologies* 19, 3 (Sept. 2014), 637–654. https://doi.org/10.1007/s10639-013-9276-6

[14] Scott Carter, Laurent Denoue, and Daniel Avrahami. 2019. Documenting Physical Objects with Live Video and Object Detection. In *Proceedings of the 27th ACM International Conference on Multimedia*. ACM, Nice France, 1032–1034. https://doi.org/10.1145/3343031.3350581

[15] Scott Carter, Pernilla Qvarfordt, Matthew Cooper, Aki Komori, and Ville Makela. 2018. Tools for online tutorials: comparing capture devices, tutorial representations, and access devices. Preprint http://arxiv.org/abs/1801.08997

[16] Scott Carter, Pernilla Qvarfordt, Matthew Cooper, and Ville Mäkelä. 2015. Creating Tutorials with Web-Based Authoring and Heads-Up Capture. *IEEE Pervasive Computing* 14, 4 (July 2015), 44–52. https://doi.org/10.1109/MPRV.2015.59

[17] Pei-Yu Chi, Joyce Liu, Jason Linder, Mira Dontcheva, Wilmot Li, and Bjoern Hartmann. 2013. DemoCut: Generating Concise Instructional Videos for Physical Demonstrations. In *Proceedings of the 26th Annual ACM Symposium on User Interface Software and Technology* (St. Andrews, Scotland, United Kingdom) (UIST '13). Association for Computing Machinery, New York, NY, USA, 141–150. https://doi.org/10.1145/2501988.2502052

[18] Allan Collins and Manu Kapur. 2014. Cognitive apprenticeship. In *The Cambridge Handbook of the Learning Sciences*, R. Keith Sawyer (Ed.). Cambridge University Press, Cambridge, 109–127. https://doi.org/10.1017/CBO9781139519526.008

[19] Peter Dalsgaard and Kim Halskov. 2012. Reflective design documentation. In *Proceedings of the Designing Interactive Systems Conference on - DIS '12*. ACM Press, Newcastle Upon Tyne, United Kingdom, 428. https://doi.org/10.1145/2317956.2318020

[20] Audrey Desjardins, Ron Wakkary, Will Odom, Henry Lin, and Markus Lorenz Schilling. 2017. Exploring DIY tutorials as a way to disseminate research through design. *Interactions* 24, 4 (June 2017), 78–82. https://doi.org/10.1145/3098319

[21] Jorgen F. Erichsen, Heikki Sjöman, Martin Steinert, and Torgeir Welo. 2021. Protobooth: gathering and analyzing data on prototyping in early-stage engineering design projects by digitally capturing physical prototypes. *Artificial Intelligence for Engineering Design, Analysis and Manufacturing* 35, 1 (Feb. 2021), 65–80. https://doi.org/10.1017/S0890060420000414

[22] Omid Ettehadi, Fraser Anderson, Adam Tindale, and Sowmya Somanath. 2021. Documented: Embedding Information onto and Retrieving Information from 3D Printed Objects. In *Proceedings of the 2021 CHI Conference on Human Factors in Computing Systems*. ACM, Yokohama Japan, 1–11. https://doi.org/10.1145/3411764.3445551

[23] Deborah A Fields, Mia S. Shaw, and Yasmin B. Kafai. 2018. Personal learning journeys: Reflective portfolios as “objects-to-learn-with” in an e-textiles high school class. In *Constructionism 2018 Constructionism, Computational Thinking and Educational Innovation, Conference Proceedings (Constructionism)*. Proceedings of Constructionism, Vilnius, Lithuania, 213–223.

[24] Margaret Fleck, Marcos Frid, Tim Kindberg, Eamonn O'Brien-Strain, Rakhi Rajani, and Mirjana Spasojevic. 2002. Rememberer: A Tool for Capturing Museum Visits. In *UbiComp 2002: Ubiquitous Computing*, Gaetano Borriello and Lars Erik Holmquist (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 48–55.

[25] Michael Gleicher and Andrew Witkin. 1992. Through-the-lens camera control. In *SIGGRAPH '92: Proceedings of the 19th Annual Conference on Computer Graphics and Interactive Techniques*. Association for Computing Machinery, New York, NY, USA, 331–340.

[26] Jun Gong, Fraser Anderson, George Fitzmaurice, and Tovi Grossman. 2019. Instrumenting and Analyzing Fabrication Activities, Users, and Expertise. In *Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems - CHI '19*. ACM Press, Glasgow, Scotland Uk, 1–14. https://doi.org/10.1145/3290605.3300554

[27] Pauline Gourlet, Louis Eveillard, and Ferdinand Dervieux. 2016. The Research Diary, Supporting Pupils' Reflective Thinking during Design Activities. In *Proceedings of the The 15th International Conference on Interaction Design and Children - IDC '16*. ACM Press, Manchester, United Kingdom, 206–217. https://doi.org/10.1145/2930674.2930702

[28] Pauline Gourlet, Sarah Garcin, Louis Eveillard, and Ferdinand Dervieux. 2016. DoDoc: a Composite Interface that Supports Reflection-in-Action. In *Proceedings of the TEI '16: Tenth International Conference on Tangible, Embedded, and Embodied Interaction - TEI '16*. ACM Press, Eindhoven, Netherlands, 316–323. https://doi.org/10.1145/2839462.2839506

[29] Saul Greenberg and Bill Buxton. 2008. Usability Evaluation Considered Harmful (Some of the Time). In *Proceedings of the SIGCHI Conference on Human Factors in Computing Systems* (Florence, Italy) (CHI '08). Association for Computing Machinery, New York, NY, USA, 111–120. https://doi.org/10.1145/1357054.1357074

[30] Ankit Gupta, Dieter Fox, Brian Curless, and Michael Cohen. 2012. DuploTrack: a real-time system for authoring and guiding duplo block assembly. In *Proceedings of the 25th annual ACM symposium on User interface software and technology - UIST '12*. ACM Press, Cambridge, Massachusetts, USA, 389. https://doi.org/10.1145/2380116.2380167

[31] Susan M. Harrison. 1995. A Comparison of Still, Animated, or Nonillustrated on-Line Help with Written or Spoken Instructions in a Graphical User Interface. In *Proceedings of the SIGCHI Conference on Human Factors in Computing*
Systems (Denver, Colorado, USA) (CHI '95). ACM Press/Addison-Wesley Publishing Co., USA, 82–89. https://doi.org/10.1145/223904.223915

[32] Margaret Honey and David E. Kanter. 2013. Introduction Design, Make, Play: Growing the Next Generation of Science Innovators. In Design, Make, Play. Routledge, New York, USA. Num Pages: 6.

[33] Julie S. Hui and Elizabeth M. Gerber. 2017. Developing Makerspaces as Sites of Entrepreneurship. In Proceedings of the 2017 ACM Conference on Computer Supported Cooperative Work and Social Computing (CSCW '17). Association for Computing Machinery, New York, NY, USA, 2023–2038. https://doi.org/10.1145/2998181.2998264

[34] Derek Van Ittersum. 2014. Craft and Narrative in DIY Instructions. Technical Communication Quarterly 23, 3 (July 2014), 227–246. https://doi.org/10.1080/10572252.2013.798466 Publisher: Routledge _eprint: https://doi.org/10.1080/10572252.2013.798466.

[35] Anna Keune and Kylie Peppler. 2017. Maker Portfolios as Learning and Community-Building Tools Inside and Outside Makerspaces. In Making a Difference: Prioritizing Equity and Access in CSCL: The International Conference on Computer Supported Collaborative Learning (CSCL, Vol. 2). Philadelphia, PA: International Society of the Learning Sciences., Philadelphia, Pennsylvania, US, 545–548. https://repository.isls.org/handle/1/279

[36] Anna Keune, Kylie Peppler, Stephanie Chang, and Lisa Regalla. 2015. DIY Documentation Tools for Makers. , 6 pages. https://makered.org/wp-content/uploads/2015/02/OPP_ResearchBrief3_DIYDocumentationToolsForMakers_final.pdf

[37] Jarrod Knibbe, Tovi Grossman, and George Fitzmaurice. 2015. Smart Makerspace: An Immersive Instructional Space for Physical Tasks. In Proceedings of the 2015 International Conference on Interactive Tabletops & Surfaces - ITS '15. ACM Press, Madeira, Portugal, 83–92. https://doi.org/10.1145/2817721.2817741

[38] Sampsa M I Kohtala, Jørgen A B Erichsen, Heikki Sjöman, and Martin Steinert. 2018. Augmenting Physical Prototype Activities in Early-Stage Product Development. In Proceedings of NordDesign 2018. the Design Society, Linköping, Sweden, 15.

[39] Robert E. Kraut, Susan R. Fussell, and Jane Siegel. 2003. Visual Information as a Conversational Resource in Collaborative Physical Tasks. Human-Computer Interaction 18, 1-2 (June 2003), 13–49. https://doi.org/10.1207/S15327051HCI1812_2

[40] R. Kurti, Debby L. Kurti, and L. Fleming. 2014. The Philosophy of Educational Makerspaces Part 1 of Making an Educational Makerspace. Teacher Librarian 41, 5 (June 2014), 8.

[41] Stacey Kuznetsov and Eric Paulos. 2010. Rise of the expert amateur: DIY projects, communities, and cultures. In Proceedings of the 6th Nordic Conference on Human-Computer Interaction Extending Boundaries - NordiCHI '10. ACM Press, Reykjavik, Iceland, 295. https://doi.org/10.1145/1868914.1868950

[42] Audrey Labrie, Terrance Mok, Anthony Tang, Michelle Lui, Lora Oehlberg, and Lev Poretski. 2022. Toward Video-Conferencing Tools for Hands-On Activities in Online Teaching. Proceedings of the ACM on Human-Computer Interaction 6, GROUP (Jan. 2022), 1–22. https://doi.org/10.1145/3492829

[43] Steven Levy. 1984. Hackers: Heroes of the computer revolution. Vol. 14. Anchor Press/Doubleday Garden City, NY, New York, USA.

[44] Anne-Li Lindgren. 2012. Ethical Issues in Pedagogical Documentation: Representations of Children Through Digital Technology. International Journal of Early Childhood 44, 3 (Nov. 2012), 327–340. https://doi.org/10.1007/s13158-012-0074-x

[45] Thomas Ludwig, Oliver Stickel, Alexander Boden, Volkmar Pipek, and Voker Wolf. 2015. Appropriating Digital Fabrication Technologies – A comparative study of two 3D Printing Communities. In iConference 2015 Proceedings. iSchools, Newport Beach, California, USA, 13.

[46] Debora Lui, Deborah Fields, and Yasmin Kafai. 2019. Student Maker Portfolios: Promoting Computational Communication and Reflection in Crafting E-Textiles. In Proceedings of FabLearn 2019 (FL2019). Association for Computing Machinery, New York, NY, USA, 10–17. https://doi.org/10.1145/3311890.3311892

[47] Anu Maatta and Peter Troxler. 2011. Developing open & distributed tools for Fablab project documentation. In Proceedings of the 6th Open Knowledge Conference, OKCon 2011, Berlin, Germany, June 30 & July 1, 2011 (CEUR Workshop Proceedings, Vol. 739), Sebastian Hellmann, Philipp Frischmuth, Sören Auer, and Daniel Dietrich (Eds.). CEUR-WS.org, Berlin, Germany, 5.

[48] Christian McKay, Anna Keune, Kylie Pepper, Stephanie Chang, and Lisa Regalla. 2015. A Networked Vision For Sharing And Documenting. , 4 pages. http://makered.org/wp-content/uploads/2016/01/MakerEdOPP RB1_A-Networked-Vision-for-Sharing-and-Documentating_final.pdf

[49] Yasmin Merali and John Davies. 2001. Knowledge Capture and Utilization in Virtual Communities. In Proceedings of the 1st International Conference on Knowledge Capture (Victoria, British Columbia, Canada) (K-CAP '01). Association for Computing Machinery, New York, NY, USA, 92–99. https://doi.org/10.1145/500737.500754

[50] Iván Sánchez Milara, Georgi V. Georgiev, Jani Ylioja, Onnur Özüduru, and Jukka Riekki. 2019. "Document-while-doing": a documentation tool for Fab Lab environments. The Design Journal 22, sup1 (April 2019), 2019–2030. https://doi.org/10.1080/14606925.2019.1594926
[51] Kazuya Nakae and Koji Tsukada. 2018. Support System to Review Manufacturing Workshop through Multiple Videos. In *Proceedings of the 23rd International Conference on Intelligent User Interfaces Companion*. ACM, Tokyo Japan, 1-2. https://doi.org/10.1145/3180308.3180312

[52] Lora Oehlberg, Wesley Willett, and Wendy E. Mackay. 2015. Patterns of Physical Design Remixing in Online Maker Communities. In *Proceedings of the 33rd Annual ACM Conference on Human Factors in Computing Systems (CHI '15)*. Association for Computing Machinery, New York, NY, USA, 639-648. https://doi.org/10.1145/2702123.2702175

[53] Brian O'Connell. 2017. *Design and Analysis of an IoT Usage Tracking and Equipment Management System Within a University Makerspace*. Ph.D. Dissertation. Medford, Massachusetts. https://www.proquest.com/openview/37aa22091361a5aa70d0dd203fb7f36f/

[54] Esben W. Pedersen, Sriram Subramanian, and Kasper Hornbæk. 2014. Is My Phone Alive? A Large-Scale Study of Shape Change in Handheld Devices Using Videos. In *Proceedings of the SIGCHI Conference on Human Factors in Computing Systems* (Toronto, Ontario, Canada) (CHI '14). Association for Computing Machinery, New York, NY, USA, 2579-2588. https://doi.org/10.1145/2556288.2557018

[55] Kylie Peppler and Sophia Bender. 2013. Maker Movement Spreads Innovation One Project at a Time. *Phi Delta Kappan* 95, 3 (Nov. 2013), 22-27. https://doi.org/10.1177/003172171309500306

[56] Kylie Peppler and Anna Keune. 2019. "It helps create and enhance a community": Youth motivations for making portfolios. *Mind, Culture, and Activity* 26, 3 (July 2019), 234-248. https://doi.org/10.1080/10749039.2019.1647546
Publisher: Routledge_eprint: https://doi.org/10.1080/10749039.2019.1647546.

[57] Thorsten Prante, Richard Stenzel, Kostanija Petrovic, and Victor Bayon. 2004. Exploiting Context Histories: A Cross-Tool and Cross-Device Approach to Reduce Compartmentalization when Going Back. In *Informatik 2004 - Informatik verbindet - Band 1, Beiträge der 34. Jahrestagung der Gesellschaft für Informatik e.V. (GI)*, Peter Dadam and Manfred Reichert (Eds.). Gesellschaft für Informatik e.V., Bonn, 314-318. Pages: 318.

[58] Daniela Rosner and Jonathan Bean. 2009. Learning from IKEA Hacking: I'm Not One to Decoupage a Tabletop and Call It a Day.. In *Proceedings of the SIGCHI Conference on Human Factors in Computing Systems* (Boston, MA, USA) (CHI '09). Association for Computing Machinery, New York, NY, USA, 419-422. https://doi.org/10.1145/1518701.1518768

[59] Daniela K. Rosner, Silvia Lindtner, Ingrid Erickson, Laura Forlano, Steven J. Jackson, and Beth Kolko. 2014. Making cultures: building things & building communities. In *Proceedings of the companion publication of the 17th ACM conference on Computer supported cooperative work & social computing (CSCW Companion '14)*. Association for Computing Machinery, New York, NY, USA, 113-116. https://doi.org/10.1145/2556420.2556852

[60] Jessica Schoffelen and Liesbeth Huybrechts. 2013. Sharing is caring. Sharing and documenting complex participatory projects to enable generative participation. *IxD&A* 18, 18 (2013), 9-22.

[61] Kimberly Sheridan, Erica Rosenfeld Halverson, Breanne Litts, Lisa Brahms, Lynette Jacobs-Priebe, and Trevor Owens. 2014. Learning in the Making: A Comparative Case Study of Three Makerspaces. *Harvard Educational Review* 84, 4 (Dec. 2014), 505-531. https://doi.org/10.17763/haer.84.4.brr34733723j648u

[62] Heikki Sjoman, Jorgen A. B. Erichsen, Torgeir Welo, and Martin Steinert. 2017. Effortless capture of design output a prerequisite for building a design repository with quantified design output. In *2017 International Conference on Engineering, Technology and Innovation (ICE/ITMC)*. IEEE, Funchal, 564-570. https://doi.org/10.1109/ICE.2017.8279935

[63] Sohail Ahmed Soomro, Yazan A M Barhoush, Zhengya Gong, Panos Kostakos, and Georgi V. Georgiev. 2021. TOOLS FOR RECORDING PROTOTYPING ACTIVITIES AND QUANTIFYING CORRESPONDING DOCUMENTATION IN THE EARLY STAGES OF PRODUCT DEVELOPMENT. *Proceedings of the Design Society* 1 (Aug. 2021), 3159-3168. https://doi.org/10.1017/pds.2021.577

[64] Aurélien Tabard, Wendy E. Mackay, and Evelyn Eastmond. 2008. From Individual to Collaborative: The Evolution of Prism, a Hybrid Laboratory Notebook. In *Proceedings of the 2008 ACM Conference on Computer Supported Cooperative Work* (San Diego, CA, USA) (CSCW '08). Association for Computing Machinery, New York, NY, USA, 569-578. https://doi.org/10.1145/1460563.1460653

[65] Joshua G. Tanenbaum, Amanda M. Williams, Audrey Desjardins, and Karen Tanenbaum. 2013. Democratizing technology: pleasure, utility and expressiveness in DIY and maker practice. In *Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '13)*. Association for Computing Machinery, New York, NY, USA, 2603-2612. https://doi.org/10.1145/2470654.2481360

[66] Nick Taylor, Ursula Hurley, and Philip Connolly. 2016. Making Community: The Wider Role of Makerspaces in Public Life. In *Proceedings of the 2016 CHI Conference on Human Factors in Computing Systems - CHI '16*. ACM Press, Santa Clara, California, USA, 1415-1425. https://doi.org/10.1145/2858036.2858073

[67] Maryam Tohidi, William Buxton, Ronald Baecker, and Abigail Sellen. 2006. *Getting the Right Design and the Design Right*. Association for Computing Machinery, New York, NY, USA, 1243-1252. https://doi.org/10.1145/1124772.1124960

[68] Iremnur Tokac, Johan Philips, Herman Bruyninckx, and Andrew Vande Moere. 2021. Fabrication grammars: bridging design and robotics to control emergent material expressions. *Construction Robotics* 5, 1 (2021), 35-48.
[69] Austin Toombs, Shaowen Bardzell, and Jeffrey Bardzell. 2014. Becoming Makers: Hackerspace Member Habits, Values, and Identities. *Journal Of Peer Production* 5 (2014), 24.

[70] Austin L. Toombs, Shaowen Bardzell, and Jeffrey Bardzell. 2015. The Proper Care and Feeding of Hackerspaces: Care Ethics and Cultures of Making. In *Proceedings of the 33rd Annual ACM Conference on Human Factors in Computing Systems*. Association for Computing Machinery, New York, NY, USA, 629–638. https://doi.org/10.1145/2702123.2702522

[71] Cristen Torrey, Elizabeth F. Churchill, and David W. McDonald. 2009. Learning how: the search for craft knowledge on the internet. In *Proceedings of the 27th international conference on Human factors in computing systems - CHI 09*. ACM Press, Boston, MA, USA, 1371. https://doi.org/10.1145/1518701.1518908

[72] Cristen Torrey, David W. McDonald, Bill N. Schilit, and Sara Bly. 2007. How-To pages: Informal systems of expertise sharing. In *ECSCW 2007*, Liam J. Bannon, Ina Wagner, Carl Gutwin, Richard H. R. Harper, and Kjeld Schmidt (Eds.). Springer London, London, 391–410. https://doi.org/10.1007/978-1-84800-031-5_21

[73] Jasper Tran O'Leary, Khang Lee, and Nadya Peek. 2021. A Grammar of Digital Fabrication Machines. In *Extended Abstracts of the 2021 CHI Conference on Human Factors in Computing Systems* (Yokohama, Japan). Association for Computing Machinery, New York, NY, USA, Article 376, 6 pages. https://doi.org/10.1145/3411763.3451829

[74] Peter Troxler and Harmen Zijp. 2013. A Next Step Towards FabML: A narrative for knowledge sharing use cases in Fab Labs. In *International Fab Lab Association, the 9th International Fab Lab Conference, Fab9*, Vol. 9. Citeseer, Yokohama, Japan, 11.

[75] Tiffany Tseng. 2015. Making Make-throughs: Supporting Young Makers Sharing Design Process. In *Conference on Creativity and Fabrication in Education - Fablearn '15*. MIT, Stanford, CA, USA, 8.

[76] Tiffany Tseng. 2015. Spin: a photography turntable system for creating animated documentation. In *Proceedings of the 14th International Conference on Interaction Design and Children - IDC '15*. ACM Press, Boston, Massachusetts, 422–425. https://doi.org/10.1145/2771839.2771869

[77] Tiffany Tseng and Mitchel Resnick. 2014. Product versus process: representing and appropriating DIY projects online. In *Proceedings of the 2014 conference on Designing interactive systems - DIS '14*. ACM Press, Vancouver, BC, Canada, 425–428. https://doi.org/10.1145/2598510.2598540

[78] Koji Tsukada, Keita Watanabe, Daisuke Akatsuka, and Maho Oki. 2014. FabNavi: Support system to assemble physical objects using visual instructions. *Paper presented at Fab10 2* (2014), 10.

[79] Francesco Vitale, William Odom, and Joanna McGrenere. 2019. Keeping and Discarding Personal Data: Exploring a Design Space. In *Proceedings of the 2019 on Designing Interactive Systems Conference* (San Diego, CA, USA) (DIS '19). Association for Computing Machinery, New York, NY, USA, 1463–1477. https://doi.org/10.1145/332276.3322300

[80] Ron Wakkary, Markus Lorenz Schilling, Matthew A. Dalton, Sabrina Hauser, Audrey Desjardins, Xiao Zhang, and Henry W.J. Lin. 2015. Tutorial Authorship and Hybrid Designers: The Joy (and Frustration) of DIY Tutorials. In *Proceedings of the 33rd Annual ACM Conference on Human Factors in Computing Systems (CHI '15)*. Association for Computing Machinery, New York, NY, USA, 609–618. https://doi.org/10.1145/2702123.2702550

[81] Michael Björn Winkler, Kai Michael Höver, Aristotelis Hadjakos, and Max Mühlhäuser. 2012. Automatic Camera Control for Tracking a Presenter during a Talk. In *2012 IEEE International Symposium on Multimedia*. IEEE, Irvine, CA, USA, 471–476. https://doi.org/10.1109/ISM.2012.96

[82] Patricia Wolf, Peter Troxler, Pierre-Yves Kocher, Julie Harboe, and Urs Gaudenz. 2014. Sharing is Sparing: Open Knowledge Sharing in Fab Labs. *Journal of peer production* 5, 1 (2014), 11.

Received July 2021; revised November 2021; accepted April 2022