(2023-05-01) Taylor Conference

Dorian Taylor: Conference. The 2023 Information Architecture Conference (née Summit) was held in New Orleans.... My own remark is that information architecture, to the extent that it is something solid enough to point at, has always been concerned with the structuring and organizing of information itself, as a substance in its own right. Information architecture, as I wrote many years ago, is about helping people understand their situations, and find the things they’re searching for. (sense-making)

The theme this year was change and resilience, and two topics that featured prominently in the program were artificial intelligence and structured content.

My own presentation leaned heavily to the structured content side. As I mentioned last time, it was about a conceptual framework I had developed many years ago for the purpose of bucketing quaternary-sector work product in terms of its durability, or lack thereof. The thesis of what I have been calling the specificity gradient, is that the most detailed work is also the most perishable

This/​next week I’m writing chapter 7 of my newsletter-to-book, The Nature of Software.

Some Personal News: I have been selected to be one of the twelve core researchers in the Ethereum Foundation’s Summer of Protocols program

attempt by the foundation to develop language around the societal benefits of protocols—​in contrast to say, apps or platforms.

as I understand it, I’m going to be the only one of the twelve spending a significant amount of my time writing code.

The Summer of Protocols is an opportunity to take something that has been perpetually a few weeks from completion, and take the time and resources to wrap it up and put a bow on it. Moreover, it helps me frame it in a protocol-y context, which is always what it was.

There is a certain category of tool—​barely a “tool”, really; more like a “hypermedia environment”—​that is a thin membrane around a constellation of structured data. It doesn’t do much besides display said structure, and afford adding to it, and navigating throughout

The subset within this category that I want to focus on is that of niche tools for professionals. A lot of them I would characterize as “just beyond the reach of a spreadsheet”. The problem with these tools is, if you can make one of these yourself, you can’t really justify the effort without diving headlong into the tool-making business.

The fashion right now, and for the foreseeable future, is to put these apps in the Cloud™

Such an arrangement comes with all the typical baggage:
What if there’s an outage?
What if there’s a catastrophic storage failure?
What if they go bankrupt?
What if they kill the product?

we could imagine a situation where the relationship is great, the terms are fair, the company is stable and secure, and yet: you still need something done that they don’t do.

What’s it gonna take to get it done without them involved?

The answer to this question is contingent on the extent to which you can access your data.

if you can get your data out intact (big if), can you (where “you” in this case is the actual person who is ultimately going to do something useful with the data) understand what it means?

My Summer of Protocols project, then, is to consider how this class of tools—​again, hypermedia environments—​might be made, that centres the portability of the informational content over which they operate.

The plan goes roughly like this; and with the exception of the first “step”, I anticipate doing concurrently:

Make an engine

a select handful of carefully-considered interventions are able to completely eliminate a great deal of the overhead involved in creating this kinds of tools

Rough in some tools:

you can’t get any traction without a prototype, and it costs about as much to fake one up as it does to just make the real thing, so stop screwing around just make the real thing

Do outreach: I am inclined here to use my relationships under the user experience design umbrella (information architecture, content strategy…) to solicit interest and feedback in protocol-oriented tooling

I am also keenly interested in approaching a broader subset of both academics (too many species to list here) and professionals (particularly lawyers and architects).

Write it up