D8 UX Analysis – Layouts, IA Spaces and the Principle of Definition-Usage Pairs

One of the key ideas behind the new D8 architecture is that of resources being identified by unique URLs. It sounds simple enough but, behind it, I think there are some exciting potentials for transforming Drupal’s UX strategy. I want to share some ideas about that kind of transformation here and I’ll tackle it from a few angles: ‘what is a page’; the principle of definition-usage pairs; and IA Space and URL semantics.

What is a Page?

In the ‘What is a Page’ BoF at Drupalcon Denver, I presented the idea that pages are essentially defined by URLs. In the follow up discussion on this BoF, EclipseGc adds the Context and Layout factors to the equation for content assembly in Drupal 8.

“(url + context) determines the layout, which defines the components, which assembles into a page.”

So I see the Layout selection being like this:

and the Layout itself being something like this (correct me if I've got this wrong.)

Behind the D8 thinking, which is conceptually based on the Panels approach to content assembly, there is a critical shift from a ‘push’ model to a ‘pull’ model. Currently we tend to ‘push’ content out into the web site by assigning menu settings from within the node creation page. We could say that we do the same thing by defining a url for a page output from a View.

On the contrary, the Page Manager allows a site builder to create a ‘custom page’ and assign one or more mechanisms to ‘pull’ content into that location. The simple, but important, concept question behind the ‘pull’ model is:

“What are we pulling content into?”

The simple answer is: some sort of space. More specifically, I would argue that this is an Information Architecture Space, or ‘IA Space’.

Logically, this means that mechanisms such as Page Manager, are creating IA Spaces, based on URLs, and then assigning one or more ‘recipes’ for page assembly within each of those locations.

As I understand it, the attraction of the ‘pull’ model is that it could/should be easier for site builders and content managers to produce and maintain their web sites. I agree 100% with this objective and want to explore some more ideas about how we can take advantage of the WSCCI-based architectural shifts to produce a superior UX interaction strategy. To start, I want to outline here a concept that I call the ‘principle of definition-usage pairs’.

The Principle of Definition-Usage Pairs

As we explore the requirements for a UI system for Drupal 8 we often come across scenarios where we envision components being used to build up larger ‘chunks’. Once again, let's look at EclipseGc's summary about how the Layout Manager will assemble pages:

“(url + context) determines the layout, which defines the components, which assembles into a page.”

From the UX point of view, this implies that the Layout Manager is a mechanism for assembling components. This in turn implies that the components already exist, probably having been defined elsewhere – e.g. nodes, user objects, Views, etc.

Behind this functionality there is the notion that things are defined (e.g. as ‘components’) in one context and then used (one or more times) in a different context. Definition-usage pairing is a principle that I’ve derived to create the backbone for many types of UI systems.

The definition-usage pairing idea fits nicely into the concept of IA Spaces. Web sites, as we know, consist of collections of public and non-public URLs. With that in mind, here’s a diagram showing the very broad IA Space division that distinguishes the public facing web site from its administrative areas. It can be thought of as simply grouping two kinds of URLs.

So we can think of any page that is used for administrative purposes (in the very broad sense of the word) as being essentially some sort of ‘definition’ of a ‘resource’ that is ultimately ‘used’ when presented via the publicly accessible pages. The concept of a ‘resource’ is useful when thinking about the general workflow of things being first defined and then used. For example:

• Resource definitions - where the stuff ‘lives’ as a data source. This resolves to a single address (URI).
• Resource usage - where the resource data is presented to a user. This could be multiple usage contexts and is dependent upon Role (site builder usage is different from end user usage)

So now these questions emerge:

• Which user defines a resource?
• Which user uses a resource?

And this takes us into the area of Role divisions. Let’s look at the same diagram with the ‘back end’ IA Space being further subdivided into pages that are used by Content Managers and pages that are used by Site Builders. Notice how the definition-usage pairs begin to chain.

Note: To be consistent with the ‘resource’ terminology, we could even think of nodes as ‘content resources’ that are ‘defined’ via the node creation/edit page.

So we can look at the Site Builder’s Role as being oriented around providing the various resources required by a Content Manager. For example they define content types, Views, input filters, Layouts and so on. Many of the ‘resources’ that the Site Builder defines are available for the Content Manager to use or build upon.

There is one more intriguing Role that seems to arise in real life scenarios: that of the Layout Manager. This Role is interesting because it can be looked at from two perspectives: the Site Builder and the Content Manager.

From the Site Builder point of view, the task of defining Layouts might be seen as a strategic step. In other words the Site Builder might want to identify and build all the possible Layouts that can be used for assembling content.

But I’ve often heard of scenarios where the Content Manager/Editor wants to build a tactical Layout to handle a special case in order to amplify the impact of some topical content. (The examples I’ve heard about came from news oriented and grocery store web sites.)

Given that, we could theorize that there is another intermediate Role, the Layout Manager, that could be responsible for the creation and management of Layouts. The definition-usage chaining is still in effect.

IA Space and URL Semantics

With these very different contexts for task sets in mind, let’s reflect back on the semantics of the URLs themselves. Starting from the front end, the URLs exposed to the public should ideally have some sort of hint about the meaning of the pages. This also came up in our BoF at Drupalcon: the idea that the meaning of the public facing site can be probably expressed by the site owner (client) in terms of the intent behind each of the front end pages.

Theoretically, it should be possible for a Site Builder to have a conversation with the Client (directly or via a Product Owner) about the purpose of the site and the intent for each individual page. Ideally the Site Builder might be able to create a set of URLs that reflect this in some semantic form.

(As an aside I want to point out an interesting implication of this ‘outside-in approach’. It is also possible to create an entire front end IA Space simply by defining locations as the set of business-semantic URLs. In other words, there is no technical reason why a node has to exist before the IA Space location is defined. These ‘placeholder’ locations can then be filled in with the proper recipes for content assembly as part of the site building process. This is an outside-in approach to web site creation that uses a ‘pull’ model which I believe is compatible with new WSCCI based architecture. There are other implications for improved workflow UX that I’ll go into another time.)

So what about the semantics for the path ‘node/1’? I think it’s a perfectly acceptable URL for a back-end IA Space location. In other words, it is a clear way to identify uniquely the place where the content for the given node is defined. But I also think the semantics for ‘node/xyz’ is quite meaningless in the front end, business oriented context.

In the past we’ve found a workaround for this awkward semantic dilemma via the path alias feature. But even with a semantically clean alias, we still have the underlying principle that the web page consists of a node that is ‘decorated’ with other bits and pieces to make a complete page. This is the way things are done using the ‘push’ model. I think in D8 we can do better than that.

What’s Down the Road?

Combining the concepts of Role-oriented design, definition-usage pairs, intentional web page design, core context, web services and IA Spaces into an overall UI strategy can, I believe, lead to outstanding improvements in UX for all types of users of the Drupal platform. We may or may not be able to achieve all of this in the D8 timeframe but I think it will serve us well to discuss these concepts and issues with an eye to establishing a core-UI strategy that can support our UX designers and core developers for years to come.

What do you think?