We want to give you a quick run through our ideas and current state of research for the Blocks & Layout initiative. I am working together with Useradvocate and EclipseGc to form a broad understanding.
One of the first things I want to tackle is describing how we use "context", because this is one of the most common questions. A really quick way of describing it is that context(s) are the data objects that blocks depend upon, to determine when display (yes/no) and how to display.
Context is information often required by a certain page/component in order to display correctly, for example the language of the page/component. In this initiative, we often refer to context to describe this configuration that can come from various places, but most prominently the URL.
We know the word context itself, is hard to really pin down and a fully accurate definition is probably not a useful exercise (perhaps even something we want to avoid in the UI). But as a concept it’s incredibly important, because it’s often context that makes up the “dynamic part” of a page, for example in node/% the % is a contextual argument that determines what shows up in the content block.
I have created this small video to give you an idea what we have been thinking about, much of the content below goes more in depth on what this means. Excuse me for some of the quality, next time I will change my recording setup as Vimeo seems to do weird things with it.
We have attempted to show how this influences all that we do in the creation of pages with components on them. Keep in mind that this is just a first pass, we hope to build an understanding of this all with the community.
We created a concept model, this is hopefully the first draft but this has formed after many discussions with Crell, EclipseGC, merlinofchaos and others over the past few months on how all the big parts fit together.
In the model as a whole we can distinguish three parts; the page that holds all the components, the context configuration that holds it all together and finally the components.
- Page: The page is nothing more than a few settings for layout, meta information like the administrative title/description, and a URL.
- Context configuration: What parameters instantiate a component, from language, user, entity to specific relationships.
- Components: These are all the new kind of “smart blocks” that will live in Drupal 8, anything from a menu, a view, to the content area will be a component. They have their own configuration, and potentially required context configuration.
This is a whole lot to comprehend but from a basic perspective, you will often need context configuration to figure out what and how components show up on the page when you are dealing with dynamic parts (e.g. redesigning how /node/% looks like when it’s displaying french content).
Now onto the tricky part, how does this all fit together in the flow of creating a page where you need a few context parameters to make it work. I have researched several workflows and ended up at the one below, a few general principles to keep in mind:
- Drupal Core UX, has both a broad target group as well as high aims for the usability of functionality - this concept as a whole is tricky, and needs to undergo several rounds of testing to validate the usability of the different concepts.
- People make mistakes, they will quickly move between steps occasionally missing a certain configuration item - we should accommodate for this behaviour.
- People are result oriented, we should quickly get them to the result they want and direct them to configuration when needed. Not make the Field UI mistake where we model the UI after the database model, creating a UI that is confusing for much of our userbase.
A few things to keep in mind as we explore this, which we have learned from talking to other people about this:
- Context configuration is incredibly difficult for humans, understanding which context you need to place a certain component is not something that is naturally understood.
- URL building is also quite difficult, we found in usability test that the concept of paths and constructing paths to build page is not something that is part of many of our users current knowledge.
Applying these thoughts to an actual flow, we ended up with the one shown below. It is obviously extremely simplified but should give you an idea of along which lines we have been brainstorming.
- Create a page & layout
In this step you create the title and administrative description used. This is also where you select the layout you want to use on your custom page and if you choose to do so create a custom one.
- Choose context(s)
On this step you choose which available contexts you want for your page. This is similar to the Views creation screen, where you select for what context you want to create a View. Examples of this are; Language, User, Entity, ….
- Drag in a component
This is where you get to the D&D builder, where you can search through a list of available components and drag the one you will need onto the page. The available components are restricted to the contexts you chosen to use.
- Configure the component (+ context)
When you drag in a component you will be asked to configure it (the instance), from simple data that it requires such as the kind of widget or number of links. To contextual configuration, when it requires a certain context parameter, such as the case of dragging in “node teaser” this requires a node context (which could be fulfilled from a parameter from the URL (node/%) or a custom defined one like it being node 5 or a number of other possibilities).
We wrote out a few scenarios, many many more coming up on how people would end up using this system:
- One url, with one intend showing the article (which has a paywall).
- Create a landing page for a section. Possibly context parameters, content/sports/. A few components (top 5 athletes, last 10 articles about sports, big header of the latest sport event, list of scores). Or creating a landing page for knitting products, components would be catalog of wool, available knitting pattern, chosen (fave) knitting patterns, social media chat thingie, funny knitting picture. Or knitting face off competition registration (account creation, personal info, entry fee, choose time slot).
- Page for variable content context parameter (e.g. /node%/).
|00 page overview.png||40.33 KB|
|01 define page.png||26.7 KB|
|02 configure page.png||38.95 KB|
|03 configure block 1.png||18.16 KB|
|04 add content 1.png||44.43 KB|
|05 add content 2.png||25.33 KB|
|06 add content 3.png||26.39 KB|
|07 configure block 2.png||32.31 KB|
|08 configure block 3.png||42.56 KB|
|09 dynamic data 1.png||53.17 KB|
|10 dynamic data 2.png||68.97 KB|
|data sources.png||108.14 KB|