Copperfield was a research project that aimed to find the simplest expressive interface in Eve.
Given the time allotted for the project, I chose to find motivating examples to base my work on rather than starting from scratch. These included, in no particular order:
- Wikipedia and other wikis
- Hypercard
- Persistent URI schemes
- Urbit immutable file versioning
I wanted to build a system that felt as immediately useful and eminently explorable as wikipedia. Something which could encourage both an intentional narrowing hunt for information, powerful and broad search filtering, and also random exploration. From Hypercard I wanted rich, tactile interfaces that suited the data they were meant to display and interact with. From Urbit and previous persistent URI schemes, I sought an easy way to share and refer to specific data.
The project was build around three central tenets:
- Everything is an entity
- Entities are not tied to any one appearance
- Entities can be arbitrarily queried
Each entity had a specific canonical page that represented it. Entities can be embedded on more than one page, with more than one appearance, but that URI can only ever refer to that specific entity. However, the entity pointed to needn’t be immutable in the conventional sense. Thanks to the semantics of the runtime Copperfield used, The full history of an entity was never lost, and a specific version of that entity could be referred to similarly Urbit’s versioning scheme (by simply ignoring facts in the log pertaining to the entity after the given version tag’s virtual timestamp). The page itself was just another appearance that could be used by any entity; E.g., all Query entities used the same Query appearance, which described the shape of their page. Many other appearances were available by default; such as hypertext links, lists, tables, and images. Utilizing these, a page could be built up of an ordered collection of entities with the appropriate appearances in a specific layout. The layout that the Copperfield demo used was designed to loosely mimic wikipedia, but it’s trivial to extend the concept to use custom layouts described in new entities.
As it stands, new appearances can be built directly from within Copperfield using a DSL that allows the intermixing of html and its attributes with Eve queries to dynamically bind and populate the elements; which provides all the same features at a slightly lower level. These appearances were a core part of Copperfield’s expressiveness; By allowing the same entity to be described via different appearances, a user can focus on what matters to her when inspecting the data, building dashboards, or working on a full application. Given an entity in the User collection, she may have a Diagnostic appearance that exposes parameters she often interrogates when searching for issues, a Moderation appearance for use by the administrators policing the chat rooms, and a Profile appearance which any other User may view to learn about the person in question. She may embed the first and second appearances for the same user on the same page in her administration page, if she happens to fill both roles.
Besides entities and their individual appearances, Copperfield also encouraged users to make collections, which act as directories of entities in the system. A collection is itself a regular entity, which happens to have a special “contains” link with entities which are its children. For example, the Kodowa entity belongs to the Company collection, and Chris is a value in Kodowa’s employees attribute. These collections made it possible to narrow in on entities of interest very rapidly, like web directories of old. They served as both an organizational tool for querying and a navigational aid for users who aren’t yet intimately familiar with a new Eve codebase.
The final aspect of Copperfield was it’s querying language, which received the least attention during development. It reused the previous madlib syntax, with the twist that data sources could expose multiple madlibs to provide different ways of querying information. This helped with some of the verbosity of the past incarnation, but couldn’t compare with the concision of past syntaxes. Furthermore, it was very difficult to remember the precise wordings that the madlibs required for querying. While it was a pretty good language to read, it was awful to write. The UI DSL failed marginally better. While it was painfully verbose, it had a sort of fluidity that stemmed from its ability to bind subtrees to anonymous queries within the DSL itself, which for the first time ever provided Eve with a way of building up UI as a single contiguous hunk rather than injection-based snippets.
One last gift to fall out of the standardization on pages and entities was the input/output interface in Eve. Ever since the “Syntax DSL” created shortly before I joined, we had a loose plan for interfacing Eve with the outside world which we called the Watcher Interface. The premise was that we would place certain tables in Eve under the control of external sources. Internally, Eve could contain queries on those which would cause some computation to occur when they were modified. This was the basis for input into Copperfield. Similarly, certain tables would be exposed to external agents which would be notified of deltas on them, allowing the outside world to react to Eve. Thanks to the syntax exposing every operation as a join, the watcher interface could be queried as if it were just another data source, identical to the entities in Eve itself; and since everything was an entity, those external interfaces would have documentation pages in Eve itself (as part of the page representing the Watcher Entities). These pages had live demos, API signatures, links to external resources, and anything else that might be relevant. While not technically impressive, the fluidity of having these live within Eve itself made it feel very natural to utilize them, and helped convince the team that standardizing on entities yielded a multitude of small benefits like this throughout the stack that added up into a great UX.