Taking a step back, we might consider the fundamental form in which creative work is created, recorded, and stored. Today, there is next to no standardization between digital creative tool files. While there are sometimes ways to convert one tool's file type to another, the process is tedious at best, unusable at worst. The lack of interoperability¹³ between creative tools means that all work created within a tool is confined to the limitations of that tool itself, posing a hindrance to collaboration and limiting creative possibility. If tools are meant to amplify the power of our brains and take over the mechanical aspects of human thought, limiting creation to a single piece of software’s capabilities is clearly antithetical to creativity.
Returning to our comparison between the development and design communities, the development community’s prioritization of functional standardization has led to far greater leaps in collaboration and wider scale public ownership over innovation. A culture of building things with the express purpose to be shared and built upon has created a baseline standard of interoperability within these communities. This has enabled scaled contributions on Github projects such as Microsoft’s open-source VS Code text editing software (Nick Kolakowski, Top 10 Most Popular Open Source Projects on GitHub). Interoperability has been key to sufficiently building upon each other's innovations and contributions, while spurring the field of development’s speed of innovation.
The ongoing efforts of companies such as GitHub to incentivize the creation and maintenance of open source software and programming languages is worth contextualizing. As Sidney Fussell explains in The Schism at the Heart of the Open-Source Movement, “technology firms rely on open-source licensing, a legal framework that lets users borrow ideas and pool together the insights and labor of volunteer developers. GitHub is itself built on open-source tools, and sometimes uses code hosted on the platform to improve itself.” However, the reality of open-source projects themselves begs reexamination. As Nadia Eghbal writes in her book Working in Public, “One study found that in more than 85% of the open source projects the researchers examined on GitHub, less than 5% of developers were responsible for over 95% of code and social interactions.” While there is impressive work being done to standardize computing and make development more interoperable and accessible, it still lacks the distributed ownership that incentivizes widespread interoperability.
Nonetheless, programming languages themselves have seen moderate success in standardization. The partnership between R, a free software environment for statistical computing and graphics, and Python, an interpreted, widely-used programming language, serves as a poignant example of the global value derived by interoperability. As Dan Kopf states in R and Python are joining forces in the most ambitious crossover event of the year for programmers, “[Python] will partner with RStudio [R]... The main goals…are to make it easier for data scientists working in different programming languages to collaborate, and avoid redundant work by developers across languages.” Increased collaboration and efficiency directly exemplify the benefits of interoperability at scale.
However, it is also worth examining the issues associated with interoperability. Interoperability can often slow down improvements and lead to inconsistent adoption of open standards. A poignant example of this can be found in the lack of universal browser compatibility for HTML/CSS features, which adds unnecessary complexity to web development work. Another consideration is the risk that standardization may commoditize a set of tools, thus diminishing the innovation made possible by healthy competition. An example of this can be seen in the state of web browsers today. When web developers do not properly support all the different web browsers, they inadvertently drive adoption towards their own tools of choice. This is exemplified through the contrasting support and usage of Google’s Chrome and Mozilla's Firefox. However, these considerations are largely the result of building upon a highly functional but extremely fragmented structure of programming that only implemented consistency and standards after much of the architecture of the web had already been built. Digital creative tools, however, are at a different place in their evolution. Defining interoperable standards between these tools would be altogether new and informed by learnings from similar implementations in other industries. Standardization would amplify the power of each tool and vastly expand the possibilities of digital creation.
Taking further inspiration from the development example, we can begin to visualize the possibilities of standardization if employed for digital media. We might imagine interoperable source files being stored in a repository structure that could then be opened and modified by any creative tool of choice. This would require standardization of file types, metadata, and a single substrate. Source files might take inspiration from Extensible Markup Language, or XML files today. XML files are unique in their being both human and machine-readable, lightweight, and widely recognized by almost any software tool.
Standardization would fundamentally change the tide of digital creative tools for the better by allowing in more collaborators, making space for greater tooling innovation, and expanding a project’s creative constraints beyond any one tool itself.
This concept would not only open doors to further collaboration at scale—it would also effectively turn the computer into a breeding ground for human innovation. Standardization would fundamentally change the tide of digital creative tools for the better by allowing in more collaborators, making space for greater tooling innovation, and expanding a project’s creative constraints beyond any one tool itself.
Beyond standardization, there is still more to be done within the confines of the digital tool to make it a better co-creator with its human counterpart. Today, the way that we use creative tools is relegated to the boundaries drawn by the software company who created the tool. However, when considering the ingredients needed to facilitate creativity, a common theme that arises is the need for software moldability, or the ability for the user to tailor their software to better address the problem they are trying to solve. I will argue that making tools moldable to their users’ preferences while cultivating communities that inspire and help members shape their own tools is the next logical step for computers to become better co-creators.
Returning to Engelbart’s guiding principle, computers have the power to change and expand human thought. But to do so, the software must adapt to suit the user's unique thought process. This idea shines a light on the importance of a tool’s moldability, as measured by how easily the software can be customized to the average non-programmer’s needs. As Mohamed Fayad and Marshall P. Cline state in Aspects of Software Adaptability, “Flexibility means it is easy to change the system’s capabilities in kind. For example, taking something that was a graphical system and making it sensory-or sound based. Flexibility is often harder than extensibility, especially when on-the-fly changes are desired.” Fayad and Cline highlight that there is a clear correlation between how flexible the software's codebase is and the user's experience of how moldable the tool is to their creative process.
A moldable development environment called “GToolkit” exemplifies a similar correlation within the field of development. As Tudor Girba states in his presentation about GToolkit called Molding Objects with Moldable Tools: “these tools can be customized live with very little effort. The low moldability cost, and we often talk about minutes to adapt the tools, opens new ways to approach understanding code and runtime through live objects.” In this context, moldability refers to the tool’s readiness to accommodate many different tasks in many different ways, without forcing the user to conform to any set processes defined by the software.
By simplifying and contextualizing the process of shaping the tool to their needs, the user is able to make the tool exactly what they require to foster their unique creativity.
A common argument against moldability is the increased cost of maintaining integrations or modifications that exist on top of a perpetually changing piece of software. This is a real issue, as evidenced by the fragility of plugin ecosystems such as those of the free content management system, Wordpress. However, this points to the fact that there are many different types of moldability to consider. Moving beyond building on top of existing software, we can begin to imagine what a piece of software could look like if it itself was moldable, or built to be modified by the user. As the Victoria and Albert Museum explain, an interesting example of this can be seen in the early 1960s: “by writing their own programs, artists and computer scientists were able to experiment more freely with the creative potential of the computer.” However, the evolution and global spread of personal computing since then has meant that this capability is no longer limited just to programmers. By simplifying and contextualizing the process of shaping the tool to their needs, the user is able to make the tool exactly what they need to foster their unique creativity.
No tool exemplifies moldability better than music digital audio workstations, or DAWs. DAWs such as Apple’s Logic Pro and Ableton Live are unique in their extensive ability to be customized and accommodate plugins, hardware, and files of all types. In part for these reasons, DAWs are widely loved by their users and serve as a shining example of software making very little assumptions about the user’s creative workflows. Instead, DAWs accommodate numerous paths to reach a desired outcome, in addition to providing the resources and community to teach the user how to create any missing feature themself. Similarly within creative tooling, Robofont also comes to mind when thinking of moldability. The “fully featured font editor with all the tools required for drawing typefaces” was designed to be built on top of, with customization options and integrations for a multitude of different scripting languages at its core.
Moldability as seen through scripting languages can also be seen exemplified through Actionscript in its early years. Interjectable scripting languages effectively removed the steep learning curve that users would need to climb to fully understand how to build their own tools themself. Actionscript provided users with abstracted, easy-to-understand coding building blocks, accompanied by a community of other users sharing their creations, learning, and pushing the bounds of the tool itself. Within the broader context of the community as a whole, the object-oriented programming language inspired a sense of play and experimentation in the user that served as a potent incentive to create. As Bill Gaver wrote in Designing for Homo Ludens: “The designer’s role in this is not like that of a doctor, prescribing cures for people’s ills; nor is the designer a kind of servant, developing technologies that people know they want. Instead, designers should be provocateurs, seeking out new possibilities for play and crafting technologies that entice people to explore them.”
Pioneering users that share their creations and anecdotally attest to the tool’s promise can be seen as toolmakers. Toolmakers are essential to bringing moldable software building blocks to the average user — the toolmaker’s shared creations serve as invitations for the average user to join and create something themself.
ActionScript and Flash attest that the success of a moldable tool often comes down to the tool’s ability to inspire exploration and spur a vibrant tooling community. Pioneering users that share their creations and anecdotally attest to the tool’s viability and promise can be seen as toolmakers. Toolmakers are essential to bringing moldable software building blocks to the average user—the toolmaker’s shared creations serve as invitations for the average user to join and create something themself. However, it is also vital that the tool’s moldability is abstracted enough to be widely accessible—usually meaning that the interface should be controlled visually and require no technical knowledge. Positioning a tool in this way allows toolmakers to lead the way and inspire average users to mold the tool themself.
Making tools adaptable to their user's thought process is the first step in facilitating more human creativity with computers. Baking flexibility into software is also in some ways advantageous for the software’s business. Moldable tools allow the user to build for their own needs as opposed to relying solely on the software company to deliver. This process also fosters a sustained sense of personal ownership and loyalty to the tool. Furthermore, the communities that emerge out of moldable tools demonstrate the creativity and collaboration that come as a result of ownership being shared between the software creators and the software users. Allowing the tool to be customized and built within a collaborative community serves as a powerful example of how we might facilitate greater creativity with these tools. This concept also suggests that we consider alternative ways in which digital tools could abstract inefficient areas of the creative process.
Considering how digital tools can be more efficient throughout the creative process from exploration to production, it becomes clear that moldability is key to accommodating the different stages’ needs. Beginning with the exploration stage within the example of interface design, a simple solution to abstract complexity and increase efficiency is to temporarily minimize options. Providing a simple, scalable interface with existing primitive elements and safe guides would help the user feel that making contributions is easy, simple, and reversible. This simplified tool would function like a lightweight scratchpad, providing both inexperienced and experienced users with predefined components and allowing them both to experiment rapidly. Offering predefined elements (shapes, text, symbols) directly exemplifies how a digital tool can augment human intelligence by allowing the user to get into the creative flow faster and minimize unnecessary construction work.
Combining the concepts we’ve covered thus far brings us to the following conclusion: Computers have, since their inception, been a rigid tool that the human user has had to adapt to use. This limits what can be done with the tool because not everyone knows how to operate the machine in the precise way it requires, nor how to go about changing it to fit their needs. However, through standardization, moldability, and abstraction, we can dramatically expand the utility of computers while broadening their capacity to help more people solve their problems creatively.