Since Zotero’s earliest days, our users have clamored for better support of historical manuscripts and, later, images. Zotero after all was developed by the Center for History and New Media, and as historians began to conduct their archival research with digital cameras instead of pencils, why shouldn’t Zotero help them? And years later when we sketched out and then launched development of Tropy, why did we choose to develop it as a separate application rather than add its functionality to Zotero?
From the outset, Tropy was developed as a desktop application using the Electron software framework. In contrast, although available as independent piece of software since 2011, Zotero was initially developed as a Firefox browser extension (XUL/XPCOM). Today this legacy imposes some limits on our ability to redesign Zotero’s look and feel, but under the hood Zotero’s performance continues to improve dramatically, most notably with the recent release of Zotero 5, with its comprehensive rewrite of the core functionality and a new, more efficient sync mechanism on our servers. Nonetheless, despite the flexibility of Zotero’s development environment and the ingenuity of Zotero’s developers, Zotero’s underlying development environment is unsuitable for image manipulation, which is of course at the heart of all of Tropy’s core functionality.
At a high level there’s a lot of similarity between the XUL/XPCOM and Electron platforms: both depend on JavaScript, and both are essentially browser shells, one based on Firefox, the other on Chrome. One could argue that platforms change, and software gets ported; indeed, significant changes are already underway at Zotero along these lines. But even if Zotero were to move to Electron tomorrow, it still would not be appropriate for working with archival photographs. And if we were designing Zotero from scratch, today, we would likely wind up with essentially the same UI and the same functionality as it already has.
Why? Because the key constraint on Zotero’s development is its audience: Zotero is aimed at scientific researchers who are collecting, sharing, and citing research materials. By “scientific researchers” I don’t mean the people working in the physical sciences or indeed any particular discipline, merely that we’re talking about formal research, not scrapbooking. People certainly can (and do) use Zotero for scrapbooking, but Zotero is not developed with this usage in mind. By “research materials” I mean bibliographic objects. Archival photos and their underlying physical objects can be (and are) cited, but in the grand scheme of scientific research, they are outliers. To shoehorn this functionality into Zotero would sharply limit its utility, and it would cripple the software for the millions of Zotero users who will never photograph a single archival object. Conversely, Tropy’s development is shaped by the single imperative of imposing some order on the growing mass of digital archival photographs collected by a relatively small population of researchers, mostly historians.