I am, by all accounts, an independent researcher. In general I focus on slow trends and neglected problems in the digital landscape, and generate open-source tools and techniques that help solve them. The way this has worked so far is that I pick in broad strokes what I'm going to investigate, and then find organizations whose needs dovetail with those targets in finer grain. Clients get their problems treated—and their staff trained—first. So far, this has happened in something of an ad-hoc way.

In 2019 I am trying something a little bit different: I am publishing a set of themes for the work I'm currently best set up to pursue. If it works, I will make it an annual thing.

Theme Zero: Data Sovereignty

Possession is nine tenths of the law

In a little over a decade, software as a service, otherwise known as the cloud, has mushroomed. For a number of very good reasons, a hosted service, sold by subscription, is rapidly becoming the de facto method of providing business and professional software. However:

While incredibly convenient and easy to get into, cloud software companies are extremely conspicuous hacking targets; they are liable to outages, bankruptcy, or acquisition by (your) competitors; they are profligate data miners, and on average they are, often by design, difficult to sever relations with.

The idea of data sovereignty is, for customers of these services, to establish strategies for improving one's bargaining position, where the extreme solution is running the service yourself. For providers, it's about designing products and services where privacy, customizability, and exportability are principal differentiators. A growing number of organizations fit both of these descriptions at the same time.

[image here]

Some services are more commodity, while others are more idiosyncratic. Open standards, unsurprisingly, track with commodity, while breadth of features tracks with idiosyncrasy.

The Program

The program of this theme is to come up with a set of methods for grading both the sensitivity of an organization's data, and the peculiarity of the necessary operations over it, as well as costing alternatives to SaaSor just plain alternative SaaS. The goal is for a user of the resulting technique to make more prudent decisions regarding their relationships with vendors, and ultimately figure out the right mix of information infrastructure that is delegated, and infrastructure that is developed on-site. The same process can be applied to vendors, to anticipate the inevitable: a more sophisticated clientele.

Theme One: The ABCs of Content-Driven Systems

Decoupling Access control from Branding and Content

Digital designers of all kinds talk endlessly about the importance of separating content from presentation, but I argue there is a third consideration, and that’s who gets to see what. Overwhelmingly, access control is coupled to the application, and this makes it hard to provision, extend and integrate. The net effect is that to get through their day, people need a zillion different usernames and passwords in a hodgepodge of systems that do not interact with one another. The goal here is to figure out design patterns for (primarily Web-based) infrastructure software (CMS/ERP/CRM) that fully decouple the access control functionality from the content and the presentation. The result is simpler, more secure systems that work better for users. ABC:

The Program

The program of this theme is to define a set of technical criteria that afford the clean separation of access control from content and presentation in a Web-based information system, including the development of technique for modulating the presentation based on whether or not a user is authenticated, or, if authenticated, what access level they have. The proposition is to solve for the general case using open-source implementations of open standards, and where necessary, tailor the solution to specific platforms used by the client.

The Client

This theme is crafted mainly with companies in mind, who in some measure make Web-based software, and whose team is already fully loaded down with existing product development. The idea is to produce something your team can assimilate into a future revision of your product, without having to read a lot of specs and write a lot of prototypes.

Theme Two: Documents Make Lousy Documentation

Disencumbering organizational reference material

Documents—deliberately-prepared, edited, curated, formatted, sequences of content—are great for telling stories. They're great for conveying arguments. However, if you already buy the argument and you're just looking for facts, documents have a number of characteristics that, when compared to newer—as in invented sometime in the last few decades—technology, simply get in the way.

We are 30 years into the Web, meaning we are 30 years into a robust and mature global hypermedia system. Why, then, are we still so preoccupied with documents? Why do Word, Excel, and Powerpoint (and their Google and PDF-taxidermied counterparts) still dominate? Why, when we need to locate some intraorganizational reference material, do we still have to slog through simulated paper where the information we want is buried in superfluous exposition? Especially now, in the burgeoning era of design systems, which are inherently hypertextual?

The best kinds of references are the ones that get you in and out with the information you need with the least overhead lost to searching and scanning. It is also important to be able to filter, aggregate, reformat, and ultimately repurpose said information, so merely indexing your documents for full-text search doesn't finish the job. What it means is hypertext. There are two obvious targets under this theme:

  1. How to go into an organization and dissolve a corpus of documents into a tight hypermedia reference,
  2. How (e.g.) an agency could package and deliver such an asset to a client.

Theme Three: Cool URIs Don't Change

How much value gets lost to broken links?

, the inventor of the Web wrote a memo. Its title, infamous in some circles, is the same as this segment. Its message was simple: there is no excuse for broken links, at least within the confines of a given website. Two decades on, this problem has still not been solved—or perhaps more accurately, the problem has been solved, it's just that the solution is not evenly distributed.

In raw technical terms, stable addresses and unbreakable links are not that big of a challenge: I have been running 404-free websites on a shoestring for well over a decade, ever since Sir Tim's memo first came on my radar. While I have developed some techniques over the years, I have yet to make them work past my own idiosyncratic process and infrastructure.

Deploying this technique is at least as big a design problem—and a organizational problem—as it is a technical one. First, somebody has to care, and caring about unbreaking links has to be somebody's official responsibility—that is to say content governance. Next, development processes have to be changed—in my opinion only slightly—to accommodate the policy. Finally, the technical infrastructure needs to be modified, which can be a small job or a prohibitive one, depending on the particular products in use.

The benefit of exploring this theme is archive-grade reliability for information resources. It's a problem you solve exactly once for your organization, and your users will never again trip on a 404, as long there is an internet.