Skip to main content
KF Notes
SearchLoginLogin or Signup
Zr
Published on Dec 06, 2021

On-ramps and Up-ramps

Where do we go from here?
by Ian Reynolds
Published onDec 06, 2021
On-ramps and Up-ramps

This is the first in a series of a few posts about what I want PubPub to be. I’m trying to keep them short so that there will be more of them, and sooner.

PubPub aims to express a wide variety of content with a handful of nouns: Communities, Collections, Pages, Pubs, and Connections. Part of our pitch is that if you can recast your work in these terms, our platform can replace a small or large part of your current publishing stack, with room to grow and adapt as your work evolves. We might even hope that our users and their work will benefit subtly from this “language acquisition” process. The English and Mandarin words for patience or convenient point to overlapping but recognizably distinct conceptual spaces, and knowing them both provides a parallax view of what the concept really is. Knowing the “traditional publishing” or field-specific lingo and PubPub-ese for a work may help clarify that it’s a book, or that it’s a Collection, but really, it’s a thing unto itself.

The work of improving PubPub often involves making our nouns more powerful, and rarely involves introducing new ones. This strengthens the PubPub pitch: if you know what a Collection is, you’re already halfway to understanding how to run a submissions process on our platform. I like this way of working, and it’s clear that the people who use PubPub like it too. But it’s been helpful to define and describe this stance when thinking about two big challenges for the platform’s long-term viability, which I am calling on-ramps and up-ramps1:

  • On-ramps help bring people into PubPub by meeting them where they currently are. Funders, customers, and users have pre-existing and totally valid languages that they use to describe publishing, and they want to know if PubPub can meet their needs. Often the answer is “yes, but you must reformulate your needs using our nouns”. We would be happier saying “yes, we have a content template that’s ready-made for your needs” and doing that in good conscience.

  • Up-ramps are where that good conscience comes from: knowing that by onboarding users to PubPub we aren’t locking them into their current understanding of their work, nor ours. Ideally, there’s a wink-nudge reveal that intermediate users encounter: their “book” or “journal” is actually a composition of PubPub-native building blocks that become visible to users at the moment they might feel ready to work with them directly. But to the extent possible, our goal should be to avoid re-calcifying their work into the language of Communities, Collections, and Pubs. Instead we should aim for a second wink-nudge moment, from our users back to us — the emergent behavior of our platform has allowed them to build things that are initially illegible to us, that we’d have to carefully inspect to understand in our own terms. We’ve tasted this, and it’s wonderful.

I think this is what all creativity tools want to be: a prism that refracts human expression into emergent behavior, or a grammar powerful enough to be the scaffolding for new modes of thought. The tool wants to give rise to something more powerful or evocative than itself and then to fade into the background, even to die. All attempts at this ultimately fail, in comically recognizable ways. We build incorrect, leaky abstractions that have hard edges or run up against the even harder edges of bare metal. The inner-platform effect is the anvil that falls on the coyote in every single episode of a show that, within our lifetimes, will have been airing for a century.

So let’s give it a shot, huh?

Next (soon): A structurally-typed CMS

License
Creative Commons Attribution 4.0 International License (CC-BY 4.0)
Comments
7
?
Login to discuss
Deepak Jagdish:

Notifications yay

Gabriel Stein:

sup?

+ 1 more...
Catherine Ahearn:

I see this play out in new/potential user calls all the time. We start with them telling us about their publication and then use that info to translate it into PubPub terms via a demo/tour of the platform. Templates, however helpful, scare me though, I have to say. Part of the fun of these conversations is hearing how their ideas evolve based on what they see PubPub can allow. They have a sense of what their needs are based on past experiences and a sense of what’s possible, and when we put pressure on that really nice stuff can happen! Sometimes that changes very little of what we see emerge in practice, but the thinking behind it of the team, and how it moves the needle for future work they do, is key for me.

Catherine Ahearn:

In some ways I think that the PubPub terms help people re-frame their publication types in interesting ways. In the “everything is a pub” vein, saying, “ok, this collection of pubs is a book and this one is a journal” really draws the mind to realizing that the line between the two is imaginary (and, at least for digital publications, made up of metadata). I say this just to say that I think the more we can get people thinking outside of genres and formats the more often we’ll see a variety of interesting stuff on the platform. I think Collections have been somewhat successful at this. Eric’s point below about allowing for custom connection types made me think about the possibility of custom Collection types.

Gabriel Stein:

I have some thoughts on the off-ramps. Or down-ramps, perhaps, which is where we package your thing in a form that can be understood by systems that function only in a particular language while maintaining as much connection to the full PubPub experience as possible.

Eric McDaniel:

I’ve seen both good and bad examples of this in open source CMSes, specifically the ones that let you define your own content model.

The good ones expose the system in a couple of layers. The first layer is a UI that lets you stamp out classical hierarchies from a template. At the very least a lot of CMSes start with a simple content with Author, Article, Category entities that satisfies the majority of their users. The second layer is a more advanced UI with the ability to define custom models and relationships, and the third might be triggers/events/workflows like what we’re talking about with submissions.

The bad ones obviously are way too open-ended, or at worst trick you into thinking some sort of relationship or workflow is possible, but ends up being impossible without a plugin (this is very frustrating).

I think what I’m trying to say is these advanced features that power emergent behavior within a community are definitely a good thing, I think we should just introduce examples/templates with the advanced features as soon as a user encounters it, kind of like how GitHub provides templates to create new workflows from the first time you visit the Actions tab in a repository.

Gabriel Stein:

Agreed. And I think we can avoid a lot of the pitfalls of being too open-ended with a single constraint or guiding principle: PubPub is concerned with making addressable artifacts.

+ 9 more...
Eric McDaniel:

It’s fun to think about how this relates to metadata like w/ Pub Connections. I know we have a fixed subset of connection types now (review, commentary, etc.), but it would be great to get your take on how Connections (or something like them) might be used in the future to implement more emergent/community-specific behaviors.

Samuel Klein:

+1 for optional connection-type folksonomy, periodically reviewed(?) to produce new fixed types

Eric McDaniel:

I think this is a great lens to look at PubPub through. I’ll be taking this along with me in for our future conversations.

KF Notes
KF Notes
Published with