Key Definitions Analysis

One of the most important aspects of a major design process such as the UX for the D8 Layout Manager is to clearly define terms in a way that we all understand and agree upon. In particular, the word ‘context’ is subject to various interpretations as we learned at Drupalcon Denver. To that end, User Advocate, Bojhan and EclipseGC have been discussing some of the key terms in order to arrive at useful definitions. Below are the results of our discussions.

Component

A component is a content source. There can be different levels of complexity involved with defining a content source. A simple one is a node or a ‘custom block’. A more complex one is a view.

It’s worth mentioning that some components will be ‘static’ (i.e. unchanging) while others (the more complex ones) will be ‘dynamic’ (i.e. the content varies). Examples of dynamic content: a View that shows teasers of the the last five blog posts; a twitter stream; a list of 'Hot content this week' items. Our analysis of these user stories also indicates that the complex components require a degree of configuration before they can be fully operational on the page.

We expect there will be libraries of components that the site builder can choose from in order to add content to a page.

Block

We need to understand what is implied when we talk about ‘displaying a block’. If everything is output through a block, should the site builder care about something being a block? No, not really. A block is simply an instance of a used content source, as opposed to an available content source. No one will ever have to explicitly select a block or create one. Blocks automatically get created when a content source is assigned to a given region. So we can actually remove this term from our UX lexicon and just let the developers use it for their stuff.

Region

On the other hand, a region requires explicit choices on the part of the layout manager user. They choose which arrangement of regions they want to base the page assembly on. They choose which region to assign content to. A region really gets down to being a group of components that appear together (basically in a div) on screen.

For the themer, this corresponds to a variable. A 'variable' is a chunk of ready-made html that is added to the mix when the final page is being rendered. An analogy is car assembly: various parts like the bumper, the windshield, the engine, might be made by different manufacturers but are all put together into a final product on the assembly line. In Drupal, the product of that final assembly is the web page.

For an end user, a region would be experienced as all the things in a sidebar versus the items in the header versus the stuff in the main content area, etc.

Layout

A layout is an arrangement of regions. For example a typical web site might have a top region, two side bars, and a central content area. These collections of regions can be named and made available for reuse. At some point we will have to work out how to work with regions in a way that supports responsive design - i.e. their relative placement on a screen can change. A ‘mobile first’ approach would presumably place emphasis on their relative importance with regard to content.

Ultimately a layout will contain components assigned to its various regions. We call this a ‘populated layout’ and that is essentially another name for a page. Whereas the ‘empty’ layout is available for reuse, the populated layout is a specific instance that belongs under a given URL. There may be other populated layouts assigned to that URL and the one that shows at any given time depends on certain contextual factors (which we will have to define very specifically as we move forward). The only way a site builder will be able to reuse a populated layout is through a cloning technique.

Page

So a page then is a populated layout that has been assigned to a particular URL. It’s an assembly of configured components (content sources) that have been placed in their various regions.

Context

The essential job of the Layout Manager engine is to retrieve content through selected Content Sources (components). That content is stored in the database so really what the engine does is assemble and utilize various techniques for querying the database to fetch that content. For example a given component uses a View and the engine uses that View to get a set of nodes.

Thinking a bit about this capability, what this implies is that the engine rummages around the database looking for our stuff using various ‘clues’ that we provide it. Those ‘clues’ aren’t random. You can’t say just anything to the Layout Manager and expect it to find the right things. Instead, we have something that is equivalent to ‘dimensions’ and that constrains the kind of variations you can specify. These dimensions are types of context. EclipseGC has mentioned that so far the contexts (or dimensions) he’s dealt with are:

• 1. Language
• 2. Entity (e.g. node, user)
• 3. String (a set of words or characters that act as ‘semantic switches’)

In addition to these, we expect that these three explicit dimensions will come into play:

• 4. Time
• 5. Path (URL)
• 6. Active Role - i.e. not what the user is allowed to do (permissions sets) but what they currently are trying to do (their goal)

It may be that these last 3 could be handled by the ‘string’ dimension but they could be regarded as fundamental aspects of content specification. These additional dimensions can provide very powerful leverage when it comes to workflow control. For example a scenario where a given piece of content should be published for 2 days under the coming events section could use both time and path.

So if we want to move away from the fuzzy term ‘context’ we should think about how to incorporate these specific terms to describe the actual dimensions of configuration that are relevant to various component types.