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.
Video
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.
Concept model
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).
Flow
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).
Scenarios
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%/).
| Attachment | Size |
|---|---|
| concept-model.jpg | 30.86 KB |
| flow-scotch.png | 9.37 KB |
| concept.jpg | 25.87 KB |
| toolbox.jpg | 33.32 KB |
| context.jpg | 47.51 KB |
| 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 |
| workflow.png | 50 KB |
| data sources.png | 108.14 KB |
Comments
Interesting, but..
I wanted to share my own opinion on this, tried to keep that out of the initial post as much as possible.
In the second step in the flow, we require people to choose context (or possibly components). This to me still feels a bit unnatural, because it assumes I fully understand context and how the decisions I make there influence what components I get. I think most users probably have some idea, that they want component X and while they are adding component X suddenly also feel that component Y would fit in perfectly.
I believe it would be better if the system takes care of as much context configuration as possible (assumes little to no knowledge from the user on that part), providing easy mechanisms to add contexts on a page level (context tab) and/or component level (when you are adding a component that requires a context that is not available, allow them to add it there).
We need a lot of feedback, this is pretty fundamental stuff - beyond just use cases (which we are working on), we need to figure out whether this model makes any sense for Drupal core inclusion.
Defining Context
Where do the available contexts come from, the number and clarity of purpose of the available contexts will be critical to whether the model will work for site development on small and medium sites with less sophisticated developer/administrators.
I can see complete sites developed without consideration of context at all.
Where do the available
Great question! Currently, they generally come from one of two places:
1. The url path e.g. node/$node->nid, user/$user->uid, taxonomy/term/$term->tid (those id's are all we need to load a lot of useful information)
2. a global, such $user, or $_domain (in the case of domain access).
Lucky them! Contexts (which lead to relationships[that's where your head starts to explode]) are an advanced case, but very important for many sites. Lot's of these ideas are actually already built (and just need to be made more friendly for those who didn't go to wizard school). Great introduction to pages/contexts (and the rabbit holes that you fall into if you decide your interested in the subject) here: http://dev.nodeone.se/node/770
"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.chapterthree.com
blog: http://www.nicklewis.org
first components, then context
How about the reverse order:
Create a page & layout.
Drag in a component. All components are offered, e.g. "content author's picture".
System in the background recognizes that to display a "content author's picture" it needs a content nid. Offers all possible nid sources: URL, first item of a node listing view, etc.
User selects nid source and configures component.
Instead of offering a list of components limited by the pre-selected context, we offer a list of contexts limited by the pre-selected component.
I agree, layout > content or component >context w/ default
The reverse order make more sense to me as well, and if a default context was provided with options that would be even better. Often times the labeling provided in drupal and its modules are not very clear as to precisely what they do and a recommended default would let the user move on without researching the meaning and implications of each available context. This is particularly true if some of the context options were provided through add on modules or distributions, rather than the core or user defined.
Go with the workflow users already know
I had the same reaction after watching the video that you speak of here: Putting context as the 2nd step is non-intuitive.
I agree with Edith & Waterboy; I'd rather see the kind of approach used by desktop software like Keynote, OmniGraffle, etc.; users expect a workflow like this:
There will be two important parts to making this work:
Content before Context
Yes, the second step was a bit odd to me as well.
Dharmesh Mistry
UX Researcher | Acquia,Inc.
"Let the user pick content
"Let the user pick content before setting up context" was my initial reaction too.
If I'm not mistaken, though, setting up context 1st lets the system only present you with the content ("blocks") that are attainable with the context you have (e.g no "taxonomy list" block until you have a taxonomy term in the context), mitigating the overwhelming "list of existing blocks".
[edit : just as a reminder, in the current scenario, every field on every bundle of every entity type existing on the site is available as a block]
However, I'd say that
1) find the block you want to display", then
2) configure the pieces of context the block requires and that might be missing in your available context
makes more sense than
1) add some random context bits (add a taxonomy term in the context)
2) find out about the new blocks become reachable.
The usability issue about the sheer amount of available blocks and how to make it discoverable sounds better off addressed in a different way.
Every field as a separate component?
Is this what we want? Or do we want 1 block called "Field" that can be configured to display the field you want? Remember, for D8, you can place multiple instances of a block in your page, each with different configuration.
From a plugin perspective we
From a plugin perspective we will have one plugin, but it will be a derivatives plugin that returns multiple blocks (i.e. one block per field per bundle per currently available entity context), so from a UI perspective it will appear to be multiple blocks. Page manager/panels does this currently, it is not overweight as long as we limit the available blocks by available contexts.
What's the UX perspective?
I wonder if our current idea of "derived blocks" (i.e., a menu block for each menu, a block for each "block display" of each View) is a good idea or a legacy of Drupal's block system not allowing multiple instances of the same block on a page and having weak configuration tools. I'm curious to hear the UX perspective on that, and then adjust our integration of "derived plugins as a code concept" with "what does the user see in selection screens" to what makes for best UX.
Yes I agree this is worth
Yes I agree this is worth looking at. A smaller set of block types that you can then set up instances for via configuration ought to scale much better.
Same thing for Entities
Earlier while playing with the new block stuff to try and display entities, I came to the same fork in the road, do we need a block per entity-type or can we have one block and we tell it what to display through configuration? From Eclipse's mouth: "It is a fine line between what should be configuration and derivatives", but even now, I still have a hard time understanding derivatives as I have never really used them (developed with them in mind) before.
One block per field vs one
One block per field vs one single "field" block where the actual field is a config param :
I guess one guideline will be the UX impact :
- What do I see when I look at the layout config page ? A series of blocks just saying "field block", on which you individually need to click to see the actual field name, would be a PITA. The administrative label of the block would ideally just be the field name.
- Also, 'field name' as param means 3 levels of dependent configuration : selecting a field name gives the list of applicable formatters, selecting a formatter gives the list of formatter settings.
This is starting to be a little implementation-specific for the scope of the current thread, but connects to how implementation (features of derivatives) impacts the UX (flow of configuring and adding blocks, number of blocks)
Agreed
I agree, I don't think that showing really generalized blocks (entity type block, field block) will be intuitive. I guess I was trying to make a point about the alternative to the derivatives approach. We could have those really general blocks only, and just show pre-configured versions of them in the UI, in my opinion this would serve the same purpose as derivatives. So we can have 1 plugin that really is 100 plugins (derivatives), or we can have 1 plugin that can be configured in many ways. I guess in the end it makes very little difference, as in essence a derivative plugins are in effect a pre-configured version of a more general plugin. It is more a question of implementation more than of the end result.
No, what you just defined IS
No, what you just defined IS derivatives. The effect of the derivative is 2 fold:
1.) We get to preset information in the UI to be more informative (i.e. the user doesn't need to just click "field block" they can see that this is the "Image: image_field" block.
2.) Since we needed to actually parse down through entity type and bundle the field is attached to, we have all the information at our disposal to skip any sort of configuring of those details, thus better user experience here too.
This is what a derivative exists to do, so yes in thinking through this, you've ended up at the reason derivatives exist at all, and conceptually you've done it the same way.
I think UX details of this aspect are clear at this point, so I won't hammer on them any.
Eclipse
Ok - then this means we do
Ok - then this means we do show one block per field in the "available blocks" list, right ?
So, yched is correct with
So, yched is correct with regard to limiting of available blocks, as well as the vast number of blocks that will ultimately be available (imagine a site with a "node block" that shows EVERY NODE as an available block... you're going to want some sort of limitations on what shows, and a site like d.o... well just think about that a little more before we go seriously suggesting it). This same logic applied to terms, I recently heard that d.o has over a million taxonomy terms. Any sort of block creation that provided EVERY term as a block would again destroy a UI under such circumstances.
Is "context" sort of a difficult concept? yeah no doubt it is, but it's not so difficult that it should be pushing regular uses away. There are some refinements to the interface that could make this a bit more straight forward, Page Manager makes this complex by not showing the relationship from one "context" to the next, which is easily solvable, likewise, it complicates it's UI further by showing all available tokens for the chosen contexts, and really we can fix both of these things and provide an much simpler, unassuming interface with which people can play with hopefully a LOT less intimidation. (Ultimately UI tests will have to bear this out, but I consider it VERY possible)
I think the disconnect here is that people have to actually PLAN what they want to build. There's room to play for the purpose of learning, but this is a tool that supports site builders with a plan. It's also a tool that, when provided with sane defaults SHOULD largely provide the components that the user expects to see. If you start editing the layout of a node page, it makes perfect sense you'd have node related blocks... not taxonomy term related blocks. Likewise, when editing a term page, it makes sense that you'd have term blocks, not node blocks... if you want one in a place where it's not already loaded, you have to know how to get it. Do you want an arbitrary block? (Say a contact webform node or something?) do you want the most recently created node in this taxonomy term? Do you want ALL of the nodes that display on this page? These are non-trivial questions, and we can't just willy nilly let users place content without telling us WHAT that content is. It's a nice idea, but it doesn't hold up to actual use. You absolutely want the user to tell you what their plan is. If they can't do that (which is what the "contexts" are) then you can't help them, and our tool becomes significantly more complicated which will ultimately kill this initiative in a way that making our end users learn what a context is NEVER could.
To take this notion a step further, I'd like to redefine "contexts" for the purpose of this discussion. Contexts are Data Sources. These sources are referenced when you want something done, and not just blocks reference them. For example:
Let's say a site builder wants to customize their node bundle "article" separately from node bundle "page". Both node types show up on node/%node urls, %node indicates we're going to get a "Data Source" from the url (in this case a node) so this is where we get into a situation where we need to allow the user to tell us, based upon a data source, to use a different layout. We will have a condition plugin that says "If node->type is page, use this layout" and a separate condition that tells us to use a different layout if node->type = article. node->type is supplied by the data source. So in this instance before we're even displaying blocks, we care about the data sources (or contexts) that are available to us. This is NOT a process you can flip on its head.
I'm willing to entertain the conversation a little further, but only if someone has a real practical way to solve all these issues. Simply suggesting it might be able to be turned around is a little unhelpful without a real plan. I've spent a lot of time on the phone with Bojhan and UserAdvocate trying to convey the facets involved with this problem, and at this point I think they both have a fairly good handle on why we are suggesting this approach. I know Bojhan isn't necessarily happy with it being this workflow either, so I completely sympathize with anyone who feels like this is unintuitive, but I think now is the time for real solid plans of action with regard to UI, and I'd entertain any serious plan, but Bojhan has actively been advocating this same approach, and I still don't see any way to do this.
Eclipse
Keeping an open mind
I want to add a serious note here. Because for brainstorming around this to be effective, I want to make sure that we do really value ideas that are beyond the absolutes that EclipseGc expressed here.
We do not expect people to come up with real practical ways to solve all of the issues, after all many of you have not struggled with all of the problems like EclipseGc has in the past two years - but that does not make your concerns and ideas any less valid (especially, the new user view is super important!).
We do really need to get faster to the meat of the problem, where as a user doing the configuration of context per component will mean you have to wade through an immense/infinite amount of possible contexts/data sources. Which is equally as confusing as not being able to find that block that you want, because you don't have the right context configuration.
A block for every node?
Why? Just as in my comment about fields, why do we want this instead of 1 block for "Node" that can be configured to display the node you want?
We don't, this is definitely
We don't, this is definitely NOT a best practice, but I think it's a situation that most people can imagine happening easily enough. The point is not that it WILL happen, but I want people to think about what it would be like if it did happen. This is just a singular point from which we can get a ton of blocks mentally really easily. If I enumerated all the places blocks could come from, I think most people would be lost, so I agree this isn't a legitimate argument, but I'm using it in leu of one because it's simple enough to grasp. Hopefully that clarifies why I use this, I don't actually want such a beast to exist.
I'm fine with saying that
I'm fine with saying that block per thing is completely unsupported and people can file bug reports against modules that do it. If you make a menu router item for every node now, that's also completely broken and not expected to work.
So, yched is correct with
This is again based on having a block-per-node though, whereas you could also create a block, then choose the node to display in it as part of the configuration. People are already used to that kind of pattern via things like node reference fields as well.
I agree that it seems
I agree that it seems off-putting that people would need to choose a "context" before they select a component to add to a page, but the examples EclipseGC mentions are serious problems we'll need to confront. If everything becomes a block, there's no way we can give people a list of "all blocks" to choose from and have that be usable.
I think he's also right in that the hangup might come from the fact that we're calling it context. Thinking of it as a data source or a type of component - will help manage the list of options available on the next screen. (Panels separates the idea of context and component type, but I'm not sure I see why that would be necessary in a UI like this.)
Rather than separating it into three parts, 1) layout 2) context 3) component, I like to think of context as being a small-part of the component selection process.
1) What layout do you want?
- choose a layout
2) What stuff do you want on the page?
- choose your type of component (or context)
- choose from (limited) components
- place the thing you chose in the page.
Then there are some additional/optional steps as Bojhan addressed in the video, of configuring the components (and configuring the pages as well, but we haven't gotten into that yet).
I also agree with EclipseGC that a lot of smart things can be done by default with core, like setting up node pages, user pages, and taxonomy pages in a way that the context is already defined for those cases. This will help us "lead by example" and keep the interfaces more manageable.
I would also like to stress the importance of keeping words like "entity" and "taxonomy" (and maybe even "context") out of the UI - especially if we're going to add the context selection screen as part of the page building process. People who want to add a blog post will never choose "entity" instinctively, but that's a whole other battle ;)
http://www.jenlampton.com | http://twitter.com/jenlampton | http://jenerationweb.com
entity tokens
We already sort of have this problem with tokens. I have a website with many fields where the "Click a token to insert" list is probably over 1,000 items. But the only problem I have with it is that for some reason Firefox & Firebug chokes on the JS. No problem in Chrome. It's completely transparent and managable, even my clients know how to use it, e. g. they themselves can customize site emails and construct Simplenews newsletters.
Problem is a little
Problem is a little different. For the most part the token browser is showing you already which tokens you can use in context (if it's called correctly) the problem is the fact that tokens are nested. This is an issue that Token module looks to solve performance-wise but isn't really related here.
Senior Drupal Developer for Lullabot | www.davereid.net | @davereid
Am I right in thinking that
Am I right in thinking that when you create a page the different node types are different Contexts?
My main worry is that I think the Drupal Process of "Add content -> Event" and then you get a screen where you fill out event related data, is really intuitive. Will this stuff you're proposing change that at all? Or is this for more advanced pages and layouts?
Secondly regarding layouts, although this changes based on the first question. I find people get scared off by the "Panel Node" idea of selecting a layout first because usually if I'm adding an event I just want it to work. I only select a new layout if I find the one I'm working with doesn't work. So we have found Paneliser is a much better way of people getting into panels where you create your page first with sensible defauls set up by a site builder and then can change it later if the defaults don't work for you.
So what will happen to the normal Drupal steps of. Setting up an event content type and then end-users being able to "Add content"? Does this just simple add a layer of flexibility on top of that (and so provide lots of defaults OOB) or will this impact that workflow?
Add content -> Event will still work
I think we're still running into terminology issues for the word Page. In this thread, I think the word Page refers to a collection of URLs (e.g., node/*) sharing the same layout and block configurations. Many non-developers use the word Page to refer to a specific URL (e.g., node/5). For this comment only, I'll use the term "Page configuration" to refer to the former and the term "Page" to refer to the latter.
By default, Drupal 8 will either ship with a single Page configuration for all node URLs, or will semi-automatically create a Page configuration for each node type when the node type is created and semi-automatically update this configuration when fields are added to or removed from that node type. Which of these approaches we go with depends on figuring some more stuff out with respect to how best to integrate fields as blocks. The page management UX discussed in this thread relates to providing the site builder with tools for creating Page configurations different from these defaults, but I can't imagine us not providing these defaults.
So, when a content editor goes to Add content -> Event (or any other content type), while they think they're creating a new page (in the sense of a new URL containing content for reading), they are not creating a new page configuration (what the word Page refers to in this thread outside of this comment). So nothing in this thread changes that, but check out and give feedback on the content creation UX thread if you're interested in that.
Some key definitions
Yes, I think the discussions can be very tricky without consistent and accurate definitions. Bojhan, EclipseGC and I discussed this and arrived at a set of definitions for some key terms. Posted here http://groups.drupal.org/node/226019
Michael Keara
User Interface Systems Architect,
The User Advocate Group
Thanks this makes sense.
Thanks this makes sense.
Summary of 2 hour long IRC discussion
Thanks for all this feedback! This is a vast topic, which as the comments shows has many usecases and levels of knowledge to consider. I spend yesterday with webchick, jenlampton and EclipseGc going over some of these concerns - although we did not solve it, we did generate more understanding and ideas.
I would like to start by recognizing that doing context/data source configuration up front is indeed, very tricky from a user experience standpoint because a large part of our user base has no knowledge of this concept. This was also my concern, and I am glad this concern is shared amongst the community.
The reasons expressed in EclipseGc reaction, mostly express the point of view that its going to create an exponentioal list of possible blocks. This list will be difficult to manage, and maybe even unpossible because of blocks exposed through relationships.
The problem, with not doing the step 1) create page, step 2) add stuff - is that you break with the way that people think building websites work (keep in mind, that Drupal's response has often, been to answer that with "so what" - which resulted in many of our site building tools difficult to understand). This is where we started thinking that the 80% usecase is likely focused around 1) Making a landing page, with no dynamic argument driven blocks, 2) Making a page for a term/entity/user dynamic argument driven page. We could just provide context/data source templates for these usecases, and move the 20% usecase of relationships + combining many different usecases to the back of the UI.
Our discussion ended in the following suggestions:
We did not yet solve the meat of the problem, which is how do users know, which context configuration gives them - what blocks?.
There are many ways to possibly solve this, we explored the idea where adding a context/data source will show you a list of possible (but not all blocks). EclipseGc suggested doing this by creating some kind of hybrid interface, where context configuration is in the same window as component library, where one could easily add new contexts and see which components come avaible.
We would love other ideas around how to solve this problem, templates are a way to learn by example. But in the end are they a shortcut, the problem of learning what context/data sources make which blocks available is still too hard.
Any ideas on how to solve this?
Does D7 Context or Layout Manager provide a guide?
I like the notion of hiding more complex "custom" stuff under a button, and handling the 80% use case. I hope this is possible; I acknowledge the difficulties.
There are two other places that have tried to tackle the problem of block discovery / use, and layout management that haven't been mentioned yet in this thread: Context & Layout Manager. I don't suggest either module has done it well; they're just ideas, and modules that I have a little experience with. Bear with me as I point out some things about them; an actual proposal follows.
First, look at the Context module. Though the UX sucks pretty badly, the core concepts of Conditions and Actions still seem pretty intuitive for non-experts (if they're simplified a bit).
Note specifically that under the Blocks action, all Blocks are grouped. The groups may be a bit Drupally, but I've found that non-coders can learn to understand the grouping reasonably quickly.
Next, look at the Layout Manager module. There are three relevant things.
Proposal
Let me make a design proposal. NOTE: I think the "80% use case" should be optimized for the user persona Ellie.
1) Simply start with "create a page", and then provide an empty canvas with a single column, empty canvas onto which they drag content components, a'la the Layout Manager.
2) Provide a way in the UX to select the context for which this layout is being set - possibly similar to how the Context module does it (e.g. a Dropdown of all possible contexts). The UX should default to a Node.
3) Provide a list of elements to drag into place.
I'll see if I have time to mock up my ideas with Balsamiq today; these wouldn't be actual UX proposals as much as ways to illustrate what I'm saying.
Jay, Thanks for doing the
Jay,
Thanks for doing the digging on this. I'm going to reply, but not just yet, but I wanted to let you know I wasn't ignoring you.
Eclipse
Context configuration
@Jay Thanks for your thoughts! We did look extensively at many of the modules in this space, for me even simply to graps the complexity of it all. However the modules you refer largely bypass the complexity that we face.
The core of the problem is in your step 2) in that some components that a user has dragged in will require a context argument that isn't set. Which means that per component you drag in, you would have to set the context argument - specify its Node, then go down the list of options till you reach the correct context argument. This is reallly where almost all of the discussion is on, is - how do we make that more usable, because spiraling down all the context configuration per block is too complex and doing it per page means its magic what blocks show up. Panels actually does this somewhat, it is worth a look.
Terms is a better example, you build a page that only applies deep into your taxonomy which has a url of /vocab%/term%/term%/term% - if you are dropping in the term body, you would have to specify that for it to work you will need the term ID, from the 3th place in the URL. This is still relatively simple, but how does this scale to when you need to add in an argument for content type, language, maybe even relationships?
I am not really concerned that Ellie, will have any trouble making pages that requires no context arguments (landing page, static blocks page) - this should be super easy. The real problem is those that do, I think that's where much of the discussion is about - because if it has a bad UX it would negatively effect the majority of our site-builder audience.
@batsonjay OK, so again I
@batsonjay
OK, so again I appreciate you doing the work to start building up your own proposal for how this could work.
I really like a lot of the aspects of the Layout Manager module. It has a number of novel things I like, but ultimately it would cripple our abilities to do the sorts of things we really want to do since it has no notion of contextual relevancy. Likewise, Context module has it's place, but I've always maintained that block placement was not amongst them. I think a clear definition of what "Context" is could help to inform why I have these opinions.
Contexts (Data Sources)
Contexts are essentially sources we can use to render content, make logic decisions, and more. Your example of Conditions and Actions is great because these also suffer from a need of contextual information in some cases. I.e. we could say "Condition: On node save" or we could say "Condition: When we save node of type article" in which case we need a reliable way (through the UI) to specify that we're dealing with nodes, and that they are in the article bundle.
From a page stand point, we have essentially 3 ways we could get contexts/data sources. CTools:Page Manager refers to them as Arguments, Contexts and Relationships:
Arguments:
Arguments are contexts that come across the url. node/%node, taxonomy/term/%taxonomy_term, user/%user, test/%test, etc, etc, etc. When a user creates a custom page (test/%test) they need to tell the system what %test is (contextually). Is it a node? a user? a taxonomy term? a raw string? the language to use? what is it? We have many many options, and the page manager needs to be informed about what it is dealing with. (The contexts I see core shipping with are probably raw string, language, and support for all entities)
Contexts:
I've been referring to these as custom contexts lately. These are very static, it's literally saying "When I'm on this page, load up node 45, and user 4 because I intend on using them specifically for some purpose." . A great example of this would be using a webform node in a side bar for a consistent "contact" form that is on all pages. It's always the same node, it's not going to change or be dynamic, so we can just specify node 45 and be done with it.
Relationships:
Relationships build off of other contexts that are already available to us (Either arguments, contexts or other relatioinships). This is normally the place where most people get lost, but conceptually it's pretty simple. We have contexts already available to us (let's say we're getting a node across the URL) and based upon that context, we want to load another context it's related to in some way. In the case of nodes, nodes specify both the language in which they were written and the author of the node. We should be able to load one or more of those "relationships" up if the site builder wants it, so a customized user profile block sitting in the side bar of your blogs would be a great example of this. We got the blog node across the url, we loaded the node author relationship which gave us a user object, and we have a block that consumes user objects in order to display custom styled profile information. This notion continues down and down and down, so if we wanted to pass the user context we just got to a view to get a list of recently written blog posts by this user, we could do that too (we could also pass the original node id through to prevent getting the current blog post in the view results as well, but I digress... you can see how this stacks I hope).
What Context, Layout Manager, and basically every other solution within this space lacks is the ability to do the sorts of things I just outlined, and while we should try to make the interface as user friendly as possible, I think we're going to find that, given the sorts of sites the Drupal is consistently doing, we'll find this stuff to be REALLY necessary, and I hope our focus here can be on building a great UI and not on cutting features. I understand that one may require the other, but I also think we'll be selling ourselves REALLY short if we go that route, and I can't in good conscience suggest it because I use the features we're discussing every single day, and they've been pivotal in accomplishing the sorts of tasks that customers are constantly asking for.
I hope my presentation of these concepts is clear. If not, please ask questions and let me explain more. I genuinely believe that if I can convey this concept people will mostly go "Oh... yeah I see your point.". At least I hope so. :-)
Eclipse
Excellent explanation of contexts
Thanks for the very nice breakdown of URL arguments, static, and relationships, and providing use-cases for each.
Yup - you're clear
@eclipsegc, I think I had a basic sense of the complexity before your description, but this added a lot. Thanks.
And I assume you understand I wasn't promoting those modules specifically; I just was using them to illustrate some UX ideas / concepts I found useful. But I'll admit your description helps me understand that they just don't handle enough.
However, though you've definitely increased my understanding, it doesn't change the fact that if we force a (novice) user to provide context first, we've got serious usability problems for Ellie.
And for now, I'm more worried about Ellie than I am Drupal devs. If the UX isn't drop-dead simple, I don't really care - they're Drupal experts. Plus, Devs have to deal with sites for a few weeks/months - Ellie has to live with it for years. And today, she hates Drupal because she has to call a Drupalist to make a f***ing Landing Page that looks different than a Node page. And my role in this conversation is to be her proxy, since the rest of you are all representing the Drupal Dev perspective just fine, thank you. :-)
In that context (hehe), I still feel strongly that my sequence above is still the right sequence: Let users start creating content by providing them a page that makes some assumptions, and give them controls that accomplish the page build purpose. Or SOMETHING like that.
It seems to me that the challenge in UX design, therefore, is to provide a way to make Step 2 in my proposal sane -- that is, how does Drupal provide a sane way to set the context once the user is already looking at a blank canvas?
This seems like a place where a good UX person (are you listening Jeff, Kevin? ;-) could help IF EclipseGC & others can make sure we've got a full listing of the needs / constraints.
Wrong "majority"
Um, ....
The majority we need to pay attention to here is NOT site-builders; we are in this situation / discussion because that's what Drupal does now - it optimizes for site-builders.
Ellie is our Majority. Please.
@jay We haven't talked much,
@jay We haven't talked much, but you are preaching to the choir (I am the UX maintainer). You are however missing my point - the use case you describe for Ellie, is relatively covered and should be easy to achieve (we basically present her all the blocks that do not need context configuration). Unless we seriously screw things up, the discussion about context configuration should not negatively impact that experience.
I agree here. Ellie probably
I agree here. Ellie probably doesn't even really need context (data sources).
example of Elle needing context
Say Elle is editor of a site like drupalize.me
Perhaps, she decides one day that she'd like to add a sidebar containing some info for subscribers. If the user is a logged-in subscriber, they should see a sidebar, and in that sidebar they should see a box (block) with info about how much time is remaining in their subscription (if it is of limited duration) and/or a pitch to upgrade to a better subscription plan or extend the membership, etc.
To Elle, this might sound like a perfectly reasonable thing to want to add, and if not in a sidebar (which admittedly would change the design of the site), then at least somewhere on each page. And yet, it does require context and relationships, doesn't it?
Christopher Pelham
Director
CRS (Center for Remembering & Sharing)
http://www.crsny.org
CRS (Center for Remembering & Sharing) is an arts & healing center located just south of Union Square in Manhattan.
Contexts: Current user
Contexts:Current user
Current Date (Actually a view could fake this, so we probably don't need it)
A Context view that returns 1 order filtered by uid for active (by date) order.
We'd then display a saved expiration date off of that order in some method. So yeah, definitely going to need contexts to accomplish that.
email software panels
I would start by taking a look at Gmail, Google Reader, or Microsoft Outlook (3 panels: context on the left, components in the middle, config pane on the right). People already know how to use those interfaces.
I really like this! Although
I really like this!
Although this may be complicated on a mobile. So for a mobile we'd probably need 3 separate screens in a workflow like suggested above. If we need 3 screens on a mobile we have to solve the same problem. If we manage to solve that problem on the mobile we might as well do the same on the desktop.
3 panel interfaces
For mobile users, would a three panel interface stack vertically then? and would that still be satisfactory?
Christopher Pelham
Director
CRS (Center for Remembering & Sharing)
http://www.crsny.org
CRS (Center for Remembering & Sharing) is an arts & healing center located just south of Union Square in Manhattan.
blocks
The idea of a large number of blocks being unmanageable is only valid within the confines of current Drupal UX practice which is to present the admin with a table including all of the "x" in your site (x=blocks, people, fields etc.) and allow them to filter or sort that list.
If we follow the OS pattern of a file/folder system, as proprietary CMSs like Adobe CQ5 and salesforce's site,com have done this is no longer a problem. The admin can have any number of blocks in their site and sort/search/organize them as they wish in a manner which may or may not map to their information architecture.
Tagging blocks
Views lets you add tags to a View, which came to be because of some sites having hundreds of Views. I like the idea of being able to tag blocks. A fresh Drupal install with no content is not likely to have more than a hundred blocks. As an administrator adds Views, menus, content types, fields, content, then potentially blocks derived from those things get created, so maybe there can be a UI step for tagging them. Tags arranged in a hierarchy can provide the underpinnings of a "folder system" concept like "labels" in GMail do.
file/folder system for blocks
I understand the concept of providing a file/folder UI for entities that are actually already files stored in directories (eg images), but for items like blocks that are combinations of data and configuration, how would we do this? We would add a table to the database that stores a re-arrangeable directory of blocks? Would all blocks be added to it in some default way on the fly as the blocks are generated? or would that have to manually be added into a particular place in the table by the user in order to appear there?
Further complicating it (it seems to me) is the hodgepodge of naming conventions that are likely used for blocks on a given site. And think of the default names that Views assigns to the blocks it generates. Looking at a huge list of them and trying to pick out what one needs can sometimes be difficult.
Would it be better to provide filters/search for selecting blocks rather than a directory tree? That seems to be the direction Apple is going.
Christopher Pelham
Director
CRS (Center for Remembering & Sharing)
http://www.crsny.org
CRS (Center for Remembering & Sharing) is an arts & healing center located just south of Union Square in Manhattan.
The user wants to put thinks somewhere
One of the fundamental usability problems of Drupal is that it does not empower the user to organize thinks in ways that make sense to them.
Time and again in testing we have seen users create things (node, block etc.) and then say "where did it go?". The reason they don't know where it went is because they were not asked to put it anywhere!
In the OS model you put things in a place where you can find them later (or create sensible hierarchies of directories that others can use to find things you created). Sorting and filtering are necessary, but secondary.
There's no obvious hierarchy
Drupal definitely has block groupings, but I don't think hierarchies really exist. So the folder metaphor breaks.
E.g. there are multiple blocks related to each of these:
But none of these obviously fit "under" one or the other parent. So there's no hierarchy.
effulgentsia is onto something, though: if there's a way to provide for tags on blocks, we can collapse a big list, and even list them in > 1 group (which is likely useful)
Then, the list of block groups can be hidden under a close/open control (e.g. turnable triangle).
I still think a type-ahead search field would be useful, too.
As an illustration of how the two can work together, look at how Adium handles this.
User specified hierarchy
In response to the last couple comments, I think what tkoleary is suggesting is that the user (editor/builder/administrator) creates "folders" (term hierarchies) that meaningful to them, and that are independent of module, functionality, or site IA as seen by site visitors. Instead, it's merely a way to organize a lot of stuff in a way that makes sense to that user, to enhance their productivity in finding something from a large set. Just like GMail lets me arrange labels in a hierarchy, though in my case, I don't have that many labels, so my label hierarchy is flat, but maybe people who receive many more emails than me arrange their labels in deeper hierarchies.
One challenge with this idea is whether folders (tag hierarchies) should be per-user, or site-wide. There's possibly other problems with the idea, but I hope I understood and helped clarify the proposal.
I would prefer reusing taxonomy.module than creating something new, though there might be challenges with using taxonomy for blocks, which are not (and in my opinion, shouldn't be) entities.
I leave that to the UX people :)
I agree, that creating
I agree, that creating categorization either imposed by the system or created by the user will greatly increase the usability of this. I think this is now an established idea, its needed especially if we consider all the things that could be blocks (fields, tokens, etc. this easily yields into hundreds of blocks).
I don't think we should really deeply brainstorm on what the correct categorization (method) is - lets focus this discussion on how we make the contextual configuration a natural part of the flow. Because that is what we are trying to find a solution for here.
Just to weigh in on
Just to weigh in on this:
Blocks will definitely have a grouping mechanism that will inform where they appear within the UI. Making that grouping hierarchical is something I would like to see debated, I don't really like the notion of making it hierarchical (fwiw), but I'm also not specifically against it. Likewise I like the idea of adding blocks to multiple groups when desired, but I don't think this is something we need in core. When we discuss the UI, and how it works, and what we'll do with it, we dont' discuss customizations of this sort very often, so I wonder if it's not a little off topic. If this is "It'd be great for core to support it and contrib to implement it" then I'm totally ++ and I think that'd be pretty easy to do ultimately.
Just to recap: The intent was ALWAYS to include block groupings, also the notion of a search mechanism against blocks is also generally ++
Eclipse
Add context when needed for a block
If we accept that some solution exists for managing a large number of total blocks available on the site, then instead of asking people to add a context required by a block before being able to select the block, could we not allow them to select a block (from the total site pool) first? Then let's say the block they chose requires a node object. Can the block configuration then say "choose a node" (in order to pick a specific node, like node 5) or "pick a node from context" (if the page context already includes one or more nodes) or "add a node to context" (which can then take the user to the context addition UI, but at this point, they have a clear goal in mind (oh, i want a block to show a dynamic node on this page, so i now need to configure where to pull that node from, e.g., url, or a relationship of some other object already in my context)).
Currently, with Blocks we
Currently, with Blocks we first choose a block, place it in a region, and then add rules about where it will or will not appear. This is only intuitive in certain specific instances: we want to place a block on multiple types of pages but always in the same region.
With Panels, we start with a specific page or a specific template for a group of pages (with same layout template) and then add blocks/content to it.
Sometimes we want to specify want goes on a page or class of pages sharing a layout, and sometimes we want to put blocks/content on multiple kinds of pages.
Can we make a workflow that can allow us to do both: choose a layout and add blocks, as well as choose a block and specify all (or some) of the places it should appear? And yet have the UI look like it was designed according to the same spec and not come from two different worlds (as Blocks admin and Panels do now)?
Christopher Pelham
Director
CRS (Center for Remembering & Sharing)
http://www.crsny.org
CRS (Center for Remembering & Sharing) is an arts & healing center located just south of Union Square in Manhattan.
That was also my hope in my
That was also my hope in my initial comment above. The flow effulgentsia describes definitely sounds much more intuitive.
However, "If we accept that some solution exists for managing a large number of total blocks available on the site ... " is not a small bet to take.
Maybe just organize the list of blocks by the 'type of context' they require ? (node, user, language... - a block can require several). The 'type of context' is still the main entry point, but at least the available blocks are discoverable without having to actually set up the required context, instead of "blindly set some context first, then we'll show you what you can do with it".
So, the problem with asking
So, the problem with asking about context AFTER you pick a component is this:
You all are generally complaining about having to deal with the context ui in the first place. I get it, the concept is non-trivial, but instead of simply dealing with it, this approach displaces dealing with context once, and instead forces you to deal with it after placing every single component. I personally believe this will be beyond tedious in the long term and I suspect that it will obscure the process by which context actually works which, for the record is a serious problem in my opinion ;-)
Eclipse
instead forces you to deal
[edit : got interrupted IRL before I could finish my reply, basically I repeat what effulgentsia says in his own reply]
How so ? Even in the "setup context first" approach, once you select a block you still have to tell which pieces of the context map to which of the blocks "arguments". I guess you can provide sensible defaults based on what's currently available in the context (e.g if there's only one node in the context), but the same could be done within the flow effulgentsia describes in "Add context when needed for a block" above.
Ahh, but wait - no!
I'm splitting the hair MUCH finer than this. (Maybe too fine?)
I'm suggesting we simply provide a canvas that makes an assumption about what context you're working in (e.g. a simple Node context), and then a (e.g. dropdown) control used to select the context for the entire set of blocks on the page at once. This selection then (using JS) changes the list of Blocks displayed.
It has the same effect / function that you're proposing: determine context, then show all blocks relevant to that context.
But by putting the context-selection control on the page where the block listing / dragging is happening, and by making the 80% use case assumption about context (Node), Ellie is immediately able to do what she wants. And she then learns about new things to do by selecting a different context in the Dropdown, and watching how the Block listing changes. (Or something....)
It's getting you what you want - but via a more dynamic, and useful, and less-off-putting (I think...) UX.
@batsonjay Not trying to be
@batsonjay
Not trying to be dense here, but that doesn't sound even remotely like it gets me what I want. I see no way to make assumptions about the context. What if we have 3 node contexts at the same time? What about components that consume more than one context at the same time?
There is no page wide assumption we can make. I may have blocks showing fields for one node context and other blocks showing fields for another node context, and I can't make assumptions about what that looks like, the user has to tell me.
Bojhan, jenlampton, and I came to an agreement about models that we thought would work last night, so I'm going to to try to tweak that with him some today, and then I think he'll be posting about it. Hopefully that will bring some consensus to this discussion.
Eclipse
@eclipsegc
You dense? Nah - it's me. :-)
Ok - good brains to have found some consensus. I hope we get to see a mockup soon.
Until then, I'll shut up.
This is a little arcane from the user perspective
If we do decide to impose categorization —which I think is a good idea because of the number of blocks a given site will have—a more approachable breakdown for the user would be based on what the block contains so we could have:
-Menu blocks
-View blocks
-Node blocks (contains fields from a single node that is not the primary node on the page)
-Form blocks
-Media blocks
Can this be user tested?
Maybe others are, but I'm not complaining about having to deal with context ui. I am complaining (or rather, raising a concern) about a site builder having to deal with it before knowing why and how it connects to their goal. People are able to figure out complex stuff when there's a connection between their goal and the task.
Even if contexts are added to the page before placing blocks, you still need to deal with the concept after placing the block, because you can have multiple nodes (or other objects) in your context, so you still need to tell the block which one to use. So in that same selection interface, an option to add a new one (even if it's a link to wherever the context ui is) would make more sense, I think, than not letting you place the block at all until after you first added the needed objects to the context.
Having said that, I wonder if this can be user tested in some way before investing a lot of time building it.
We will definitely have Dharmesh test it
And hopefully in a fully functional prototype
User Testing
I strongly recommend that we do put the designs (even if half baked) in front of the users. I would be up for testing this when the time is right.
Dharmesh Mistry
UX Researcher | Acquia,Inc.
Telling it which one to use
Telling it which one to use is pretty easy, and it does default sensibly.
The hard part is that sometimes it's just not possible to actually add the context you need after you select the content.
Let's say I have created the path "products/%product".
Right there, I've already told it about context. I need to tell the system what that %product means, particularly if I want to apply some kind of access rule on it. The UI must be separate from content.
That said, we can probably make the context UI accessible from the add content screens which I think would ease everybody's problems. Hopefully the mental workflow goes like this:
"Here I am at product/%product. I want to add some information about the owner of the product. Hm, none of the user content is in the dialog, but my list of data sources says I have a product. Ahh, I can add a relationship, okay, what relationships...there's the owner. Oh look now my user content is available. Great!"
It's a very different workflow when you want to just add a specific node or something, as a whole, to a page. That doesn't necessarily even have to use context, in either today's world or tomorrow's world. You can embed those directly into the page. The problem then becomes one of selection.
Relationships before Context
"Here I am at product/%product. I want to add some information about the owner of the product. Hm, none of the user content is in the dialog, but my list of data sources says I have a product. Ahh, I can add a relationship, okay, what relationships...there's the owner. Oh look now my user content is available. Great!"
- Merlin
OK, so what if the list of contexts were generated AS IF all relationships had been added already. Then, if one adds a context that does in fact require a relationship, then the relationship gets recognized by the system and added automatically?
Christopher Pelham
Director
CRS (Center for Remembering & Sharing)
http://www.crsny.org
CRS (Center for Remembering & Sharing) is an arts & healing center located just south of Union Square in Manhattan.
That would be very difficult
That would be very difficult to automate well, since you'd have to find some way of parsing the actually available relationships and then picking one and...it's not impossible, I don't think, but hard to do well.
Hybrid++
I think the hybrid approach will bring clarity to the process, and give the user immediate feedback on how changes in their context configuration affect the components (blocks) available. So, I believe that the challenge at this point is that of how to make the context selection process as painless as possible.
Context/Data-source for Page different than for View
First off, thanks for this thread, all the thinking that's gone into it, and the excellent summary and discussion.
In the summary, for the "choose context" part of Flow, you say:
You're referring to the "Show" dropdown at the top of the Views UI wizard, right? A key difference though is that choice is results oriented. A View is all about showing an item or a list of like items, so deciding what kind of item(s) is a necessary and logical first step. For what this thread is about, building a Page, the end goal is not to show a context / data source, but to show a collection of components/blocks, each of which may have its own context / data source. And I think that's where we hit the UX challenge in leading with context selection before block selection.
so I 100% agree with your
so I 100% agree with your statements here, BUT... ;-)
I think the notion here is as it relates to building custom pages that take arguments, so if we made a foo/%test page and specified that %test was a node, this is roughly equivalent to the views analogy, and should cover the 80% use case (imo). That being said, I still firmly believe I'll be burned at the stake if we don't build a real data source administration tool, but I can frame the analogy like this, and not cringe.
Eclipse
For what this thread is
But won't the context/data source provide a fairly good indicator of the types of blocks that it will make available? I agree that is would be as concrete as views content but I don't think it is that wide of the mark?
+1000000000000 Yes you have
+1000000000000 Yes you have hit the nail on the head, this is the point I'm attempting to make.
I am glad to see that
I am glad to see that Panels/Ctools will be include in drupal 8, it is a great module.
I have a suggestion, maybe we could change the name of this initiative, change it to "Panels in core", to respect the great work that merlinofchaos have done on panels.
我的drupal博客Think in Drupal
Panels in core
To my knowledge no decision has been made to put panels in core. I think what we are talking about here is incorporating "concepts" from panels into core in some form.
We could shamelessly bring
We could shamelessly bring the idea of panels to core, i think it will be better if we respect the idea's author. Otherwise Merlin will continue write another chapter for his book "The Book of Druplicon", chapter 6, Blocks & Layouts Everywhere
我的drupal博客Think in Drupal
So is the idea
that we should avoid treading on any ground that has already been trodden by Merlin for fear of angering him? I don't think so. In fact I don't think that if we came up with a better user experience than that provided by panels that Merlin would not applaud the effort. His contribution to Drupal is pretty universally recognized as immense but panels has many well documented performance and usability issues, not to mention the fact that it is just not a unified solution to the problem because by necessity it had to fit in to the architecture of D7.
Just to level set here is the goal IMHO:
Allow the site builder to create templates and layouts in the CMS without having to edit html files or write PHP.
Allow the site builder to freely move blocks, regions, and fields anywhere they want to in their layouts and set contexts for their display.
Panels is pretty far from accomplishing the above in it's current state.
Pretty sure panels + ctools
Pretty sure panels + ctools page manager accomplishes both 1 + 2 mentioned above.
The layout building tools allow you to create templates and layouts by clicking and dragging regions around - I think it's about as usable as it gets. But that's one tool embedded among layers and layers of stuff to configure and setup, which I think is the real usability problem, especially for end users. The vocabulary is really sticky - I'm guessing a lot of people if they have to ask what is a 'context'? or what is a 'relationship'? they are not going to click on those buttons/links.
What I don't like about panels layout building tools is that your layout is contained in the content region and does not integrate with the other theme regions on the page. So you can create custom layouts and move everything freely within the layout, but it's contained within the theme's content region. I don't know enough about the architecture of why that is - but it seems to me it's a place where drupal core vs contrib modules vs theme vs panels are all trying to reach in and do something but it's uber messy.
Hope my comment are somewhat clear - overall am also just really glad to see these discussions being addressed by the community. Thank you all for your efforts, whether it's code, questions, criticism, or maybe new crazy ideas - the fact that I can see it happen is one of the top reasons I use drupal.
Panels Everywhere
Try Panels Everywhere.
I've built several sites with Panels and Panels Everywhere recently, and my biggest grievance is the fragmentation of the interface. Panels, Pages, Custom content panes, Minipanels, Views, node display tabs... having to run 5 miles around just to change a single thing on a page.
Just to clarify, I'm a
Just to clarify, I'm a comaintainer of ctools and primarily I contribute my time on page_manager, so... staying true to what page_manager/panels does in this regard is very important to me. That being said I chose NOT to name it panels in core because of the general misunderstanding in the community surrounding panels. I would, however, characters this initiative as essentially being Panels in Core, so if that's how you want to think of it, I have no problems with that.
Eclipse
How far will the labeling get us?
Great thread, really interesting ideas!
I wonder to what extent will the context name provide a good pointer to the types of blocks it makes available? Will labeling the magic door make it obvious enough what lies behind it? How likely is the progression
In some cases it will work well (nodes, users). In other it won't work well (tokens). I wonder if it does enough so the problem we are talking about is not quite as big as we imagine?
In order to clarify my own thinking about it I did up a quick wireframe (http://bit.ly/JEUhbc). I simply took the current mechanism panels has for adding 'blocks' to pages and mixed in a 'add context' element (probably not a great idea :) but one people will be familiar with). In no way am I suggesting it as a solution. It is just a tool to sketch out how far labeling might get us and other potential approaches discussed above.
Hey edward,This is an
Hey edward,
This is an interesting train of thought, we(jen, Eclipse, me) did some exploration which resulted in the following flow:
In essence it means, that you browse blocks by context type and then when you drop a component with that context type on the page, it will require you to configure the context. This configuration of context will then be applied by default to all the components from that context type, unless you specify otherwise.
Components - http://groups.drupal.org/files/toolbox.jpg
You can browse the components by context type, this will be pretty much the same experience as advocated by tkoleary - where one can just go through the blocks of a certain type. We still have to add a lot of filtering mechanisms to this. But the raw idea is that you filter to the block you want - select it and it drops onto the page. Once it’s dropped on the page you get put into a modal dialog(or something else) to configure the context arguments required for this component.
Context/Data source configuration - http://groups.drupal.org/files/context.jpg
Very simplified idea of how one would configure the Node body component its context. The first time you set it for this type of context, it will be used as the default context configuration for items in the “node” type category. We think that its a 80% usecase, that people will only use one context configuration per category - however we do not restrict them, in applying a different context configuration if they choose to do so.
We did not agree on this flow though, because EclipseGc raised a serious concern that configuring the context on component level will mean that we are ad-hoc building URL's. Which could result in people just dragging in parts creating unpossible URL structres that include node/term and user data just because they want those blocks. I am not really how to resolve this, as there is only one solution to it - is configuring context up front, without knowing what blocks it results into.
Anyone has more ideas around this? It is seems quite tricky to find a good UX solution for this.
Hi Bojhan, Thanks for getting
Hi Bojhan,
Thanks for getting back to me. What I am trying to do is accept the push back from EclipseGc and create a solution in light of this. As I understand it the push back is
I would be interested in hearing more about why you see this as such a big UX problem? I agree that the ideal would be to have the initial user flow outlined. Given the practicalities, however, I think in a lot of cases the name of the context will indicate the blocks that result from it.
I believe the trick is in making the action of adding a context as seamless as possible with adding a component. So lets introduce the idea of adding a context as a way to get more components. Take as an example
Or we could try and give some examples of the types of components that are made possible by a context (with the option to view more components if required) so that the user can get an idea of the components contained in a context without having to load in the full list. See
I don't think the images are anything approaching a solution. Its just that the proverbial picture paints those thousand words :) and I hope what I am trying to communicate is clearer with the wireframes.
I really have no idea what a
I really have no idea what a hybrid approach might look like, but here is what I think Eclipse GC is talking about (please correct me if I'm woring)
Adding something to the page, also allows you to add a context:
If you choose to add a simple component (in this example I chose content -> body field) you can either choose a "Data source" for this component, or you can leave it as "Default" and let Drupal figure it out for you.
And if you instead wanted to add a context to the page, you could define the data srouce for that too:
Am I close?
http://www.jenlampton.com | http://twitter.com/jenlampton | http://jenerationweb.com
Busted image links, Jen
eom
right-click
Right-click and open image in a new tab.
Context UI revamp
Ok, so this definitely needs some work but it's focusing on a few of the core issues we've mentioned here. I would recommend checking out http://drupal.org/sandbox/jec006/1478694. And yes, it's still in a sandbox but if it does part of what we need, then at least that's something, right?
Danielle Sheffler
Engagement Manager at Acquia
http://www.acquia.com
Need some clarification
Is this thread for how people will:
1. create new pages like you can do with Page Manager?
2. create new pages by creating a node/entity?
3. create new pages by creating a node/entity then configuring the layout and context all in one go?
Note: If #3, some entities/nodes shouldn't be displayed on there own page, so we could skip the whole page layout selection for those items. Ex. Banner Rotators
If #1, I like how http://nubook.com/ allows you to create a "page" by first selecting a layout/template that has predefined dummy content. Then you click the region to edit/replace those components/place holders.
Maybe that could then show some kind of "add here" wizard:
1. Add a new entity here?
2. Add an existing entity here?
3. Add a new block here? (shows Beans, mini-panels, boxes, etc)
---Don't see what you need? add a context to select from more blocks
4. Add an existing block here? (shows Beans, mini-panels, boxes, etc)
5. Add a field here?
---Don't see what you need? add a context to select from more fields
Each the options above would ask more questions based on what was selected. By asking questions we make the big words like context, relationships, variants, etc less scary.
While all this is happening a new variant is being created. At the end of the wizard a user could create another variation of this page. (What about variants, will this be discussed?) This keeps the 80% of the use cases first.
I do like what @bojhan showed with Context/Data source configuration - http://groups.drupal.org/files/context.jpg
Upon further reflection
So, Bojhan and I have beat this discussion to death in IRC and over Skype lately. I have some notions that we agreed would be good to share at this point. After much pushing from Bojhan over how would could allow components to be browsed w/o contexts present, it seemed obvious that we could browse both components and related data sources from existing contexts relatively easily. This should even allow us to drill down through the related data structures and pick a component that might be 2 or 3 levels deep in the system. Once this is done, the relationships and context settings that are missing would be put together with the component's configuration in a multistep form wizard of some sort. This is all still very newish conceptually, so we're exploring the edges of the box. Arguments are still manually added when defining the url for the page.
Hopefully this makes some sense:
Please help modals be a core UX option
Shameless plug: If anyone reading this is or knows a good JavaScript/jQuery developer, please point yourself or him/her to http://drupal.org/node/1175830#comment-5827302. We need those jQuery bugs fixed or some alternate solution if we want to have anything in core using modal dialogs. Thank you, and carry on with the higher level UX discussions :)
Are 'Available data Sources'
Are 'Available data Sources' contexts that have already been added to the page?
Are 'Custom Data Sources' contexts which are available but not added yet?
What lies under node in the 'Component Groups'?
"Available Data Sources" are
"Available Data Sources" are contexts that have already been added yes.
"Custom Data Sources" are essentially arbitrary contexts (say... node 5, or user 2, or any such arbitrary designation)
"Component Groups" are groupings of blocks by something other than their context. This is essentially the method panels currently uses, we're just expanding how things can be browsed. One of the key aspects here is that any component added while browsing context would be autoconfigured for the context you were browsing at the time. Components added from groups would need to have their context specified (if multiple are available).
Hopefully that make some sense?
Eclipse
Another approach (with sketches)
After reading through the comments here (phew!), I'd like to post some ideas and sketches of my own.
Some sketches
Since images are better than words in this case, I want to start with the sketches.
Layouter without data connections
Add new blocks
Layouter with data connections
Add content, then contexts
As far as I can understand, everyone here thinks that adding content first – then context – is easier for the end user. (But some feel, not without reasons, that this might be really difficult from a technical point of view.)
I think getting right into the content adding part is the best approach. That's what most people want to do most of the time – Ellie too. As some have proposed, I also think it makes sense to add a default layout which can be changed – just to get into the content management right away.
How to add blocks with missing contexts?
Having worked with Rules for quite some time now, I think that "context input" for blocks should allow switching between context input and manual input. That is: if a block requires a node, I can either insert a node context or enter a NID manually.
If a data input fails validation, because the context is missing or manual input is awkward, the block rendering just quits. This means – no problem in placing new blocks, even if matching contexts are not available.
(In fact, I think basically all configuration should allow switching between dynamic input – "context data" – and manual input. But that's for another discussion.)
How to select blocks, then?
As has been pointed out, there will be tons of blocks to choose from – especially if we don't restrict the listed blocks based on the available contexts. I think an interface similar to selecting fields in Views would be good – it's the result of quite a bit of usability research ad it's an interface many Drupalists are used to.
However, I would like to complement the search/filter ability with an option "show only blocks matching available data sources" (or a better wording with the same meaning). This would give you:
(If my crazy ideas about having all configuration being able to accept dynamic input come true, we need a line between complex data – such as entities – and simple data – such as booleans.)
Selecting dynamic input (contexts)
In the sketches above, I use a switch "show data connections" to allow the site builder to manage context data. This gives the screen quite a bit of more complexity, but you stay on the same screen. The added information is:
(Note: In Page manager you have 'static' contexts, such as a node specified by its NID. With the approach above, this is replaced by being able to specify NID manually in block configuration.)
Damn, this is ugly
I wanna make some better sketches, that also shows the workflow for adding new blocks. I hope to be back tomorrow.
Updated sketches
I did some new sketches, and talked a while with Bojhan on IRC. A few things are changed since the last sketches, and I think I can present the workflow in a much more clear way.
Some terminology clarification
View video: 3.5 minutes
The term "block" appears in two different ways:
I have divided the term "context" into two parts:
Case one: a front page
View video: 5 minutes
In the simplest of cases, the workflow could look like this (numbers refer to diagram above):
Two things worth noting:
Case two: article's related content
View video: 4.5 minutes
In a more complex example, the page fetches contexts from the URL.
Case three: author information
View video: 5.5 minutes
Finally, we have the case where the contexts ("provided data") is not enough and context relations ("derived data") must be added. We'll use the previous example with related content.
Two new proposals
View video: 4.5 minutes
Both of these mechanisms are implemented in Rules, and I have to say it brings a lot of unexpected flexibility from a site building perspective – as it allows different components to talk to each other, since they recognize one another's input/output.
This is moving away from the user
IMHO what seems to be happening in this thread is that in an effort to preserve the complexity and flexibility of the "page built from data" that I think we all agree is what makes Drupal powerful, we seem to have lost sight of the most basic user stories.
I think the most fundamental of these are:
I am a site builder and I want to create a layout for a content type, in this case an article. In this layout I want to set the position and visibility of my fields and I also want to set the position and visibility of a set of blocks that I want to appear in the surrounding regions. I have no desire to make articles of this type appear differently for different users.
I am a content creator using the above content type to create a new article. I want to override the position and visibility of a few of the fields and blocks on this page to create a unique layout for my article.
I understand that there are many, many other, more complex use cases that we must consider and build for but what I am talking about here is the fact that if we don't make the two above effortless and reveal the others by progressive disclosure then we will be squandering an opportunity to do the thing that Dries has told us is most important: making Drupal more usable.
agreed
It should also, not require the understanding of Drupal specific terminology to accomplish common actions.
Basic user
It needs to be clear which kind of users this is adressing. If it is adressing Drupal-Savy Sitebuilders, it can be as complex as it wants.
But if it is meant to adress as nooby persons as possible, I guess something like this is what it starts from:
http://www.youtube.com/watch?v=fik-fsGAx3g&feature=player_embedded#!
Buzzr gets some things right, with all the gripes I have about it.
You have a box with stuff you can add to the site, say videos, content, a Facebook widget whatever.
If the stuff is not in Drupal core, it is of course not there.
But what is important: it needs a graphic representation that makes people intuitively understand what they are dragging onto their site.
This stuff you drag into some kind of region layout, into the sidebar, the main content, the footer wherever.
Whatever context configuration and selection of what blocks are there needs to be figured out and it is not trivial of course.
But anything beyond dragging pieces of content into a layout scaffolding will beyond a nooby user. Configuration of contexts is something they will most definitely fail to understand.
So configuring Contexts is fine, but it should be optional. You drag some stuff onto your page, maybe you are happy about how it looks.
Only if you are not, you will go and configure the thing (on what pages shall the thing appear or whatever).
Life is a journey, not a destination
Bojhan, EclipseGc, and I
Bojhan, EclipseGc, and I discussed this in-depth this afternoon. The biggest point of contention remains around the topic of how to handle showing blocks, and how required context is brought into a given layout.
It's EclipseGc's position that choosing a context first is critical because it filters the list of available blocks to only those that make sense for the given layout. For example, if you're dealing with the node/%node page there is basically not ever a reason to start dragging in taxonomy term descriptions that are attached to users.
It's Bohan and my position that moving the context selecting part first, before being able to select from available blocks, completely cripples the UI because it forces implementation details on people who just want to put stuff on their page, who often are totally non-tech-savvy. We would really prefer a situation of:
Step 1: Pick the layout
Step 2: Drag in the stuff you want (which would set a reasonable default; for example if I'm on node/%node, and a block requires a Node context, it would take it from the URL. If it couldn't figure it out, then it would prompt for it instead)
Step 3: Configure / override options after that if it's not quite right.
To resolve the "overload" concerns (which are totally legitimate) we discussed making blocks without all of their contextual dependencies met visually less prominent in some way. And a way to get to a "global" context configuration page for a given layout, but to make it more hidden away so only advanced users can see it.
The next steps seems to be diagramming out a flow of two scenarios:
1) I'm on a node/%node page and I want to bring in and position fields for this node (defaults should take care of it).
2) I'm on a landing page called /fall-2011 and want to bring in a node (node context), comments (node context) and author picture (node + user context). How does this work?
Note that I haven't had a
Note that I haven't had a chance to review Itangalo's sketches/videos, but they look like they're touching on a lot of the same problems.
Prototypes
I am really happy to see all of this work, it seems like we have already uncovered a lot of important details and are now getting to the core of the discussion.
Continuing this discussion, we have been working on two prototypes that will be able to more thoroughly explain the different positions and evaluate how they work. This all to make this discussion a bit more tangible, because I feel it is often hard to follow. I already showed this to a bunch of people, but we definitely need more feedback.
We have incorporated a small number of Itanglo’s ideas, but are still contemplating how to apply ideas like configuration in place, and filtering on available contexts. Keep in mind that these prototypes are still missing loads of pieces, we did not design every detail yet - but instead focused on the general flow.
We have only really worked out 1), although 2) should be clear from the concept too.
Prototype 1
http://bojhan.com/blocks/prototype1/
In this approach you would have a library(toolbox page) that exposes all the blocks in the system. You can choose the block you wish to add, and then when its placed configure the data source - if there is already a data source available (e.g. you configured node% in the path) it will be selected by default.
We introduce the idea of data sources, at the point of placing the block and allow them to configure one from there if it doesn’t exist.
Prototype 2
http://bojhan.com/blocks/prototype2/
In this approach you have the library that exposes all the static blocks in the system (requiring no data source/context configuration), and blocks that are available through datasource/context configuration. If you wish to add a node body, you would have to add the node context/data source and then the node group in it the node body block becomes available. This is what was mentioned in previous comments, the context first approach.
A note on this one, EclipseGc has been working on a interaction where you can inline overview the data sources. He should be releasing that soon.
There is surprisingly little difference, its really only about whether we expose all the blocks in the system or whether we only expose the ones that are available because they have correlating data sources. This is quite a tricky decision to make, because we are basically weighting the learn ability of data sources against the discoverability of blocks.
Let me try to articulate my concerns regarding the flow, of context first - I feel we haven't really captured the fundamentals - as we tend to go off in details (that often are independent of the flow we choose).
Much of my concerns (and probably webchick's), comes from the idea that it will be difficult for Ellie to deduct from the data source options, which one she is going to need and configure to get the block she wants. Data sources, if we like it or not - is a fairly technical concept and its placement in the flow is of vital importance to how usable this whole concept is.
If we place it at the end as shown in prototype 1, we gain the possibility that people can browse through the library to find the block they want. But lose the direct conceptual relationship between data sources and how they are required to make a large number of blocks work. By placing it on the end, I still feel we can adequately communicate the conceptual relationship but it is not very direct.
I feel strongly about the discoverability of blocks, because that is the end-goal of all of our users - it is the thing, people will be looking for throughout the UI and data sources is only a part of getting to that end goal. If we set up a prerequisite, that they need to go through a number of quite difficult configuration steps before they reach their end-goal we are are creating a UI that caters after the technical steps involved rather than the expected user flow.
There are many ways to solve the various problems around "overloading" with the amount of blocks, or configuring data sources for use outside of blocks. I feel most of the disagreement, is about what level of knowledge we require about data sources to be able to use anything beyond static blocks.
One thing I've been thinking
One thing I've been thinking about is that the UI to add blocks and the UI to add data sources should be very similar to each other.
Conceptually they have a lot in common. There are probably enough of them to categorize, and they may or may not require input. One place I feel I erred in my design is that relationships and "custom data sources" as they're being called in Eclipse's model probably shouldn't actually be different from each other. The only actual difference is that relationships require input and custom contexts don't. But otherwise, they're the same. Plus, if the UI to find them is the same, familiarity will make it easy to use either one. You simply have to ensure that users can tell the difference. i.e, in one UI I'm adding data for use and in another UI I'm rendering data.
That said, different ways of getting there are good. I like having an 'add relationship' button on a data source, so that you can quickly pick a relationship directly from that data source and configure it. That will help lead users down the path of knowing what data is available based on the data they already have.
Also, one important thing that I think Eclipse and I have both concluded is this: In the vast, vast majority of cases, if users need data sources at all, one will already be there. For example, if I'm creating a layout for a node page, the node that's being laid out will already exist in a data source. The most likely use case is that I need to add a relationship (I.e, a referenced entity or node author or book parent) but in the real world, that seems be mostly be what people need.
If I have no data sources at all, I'm probably a landing page and it is unlikely I'll be adding any. Instead I'll be adding views and other things like curated content. Typically, if I'm going to add a specific node that I already know about, I'm only going to add that in a single block. I don't need a data source for that. I'll probably use a view or simple node content block, give it the node via configuration or some kind of search dialog, and be done with it. In that case, I don't care if it's a data source or if it's an isolated block. Though I suppose I do have to be careful that users might have trouble understanding why an isolated block can't share the node it's using, so maybe it would be good to be able to just add that to the data source list. Of course, doing that means that the user now has to configure some kind of identifier for that node. So it adds a burden.
Finally, keep in mind that one of the absolutely awesomest most powerful and very very quietly unknown feature is the 'view context'. When a view is the data source, and you have the ability to extract relationships (I want the entity that is the 3rd row of this view, for example) and lay out that view in any manner you want, some very cool effects happen. This is not, by any means, an 80% use case. That is a feature for power users only, so my only concern is ensuring that the feature can remain available and not be difficult to use once it is known it is there.
In my last post I forgot to
In my last post I forgot to actually comment on the prototypes. In general, I think I like the direction that we're going. Add data source as a link on the add block dialog seems valuable. One option to think about might be tabs, as well. An add data source tab and an add block tab on the same dialog might make it relatively natural to just switch between the two interfaces, especially if they work very similarly to each other.
So I wanted to take a little
So I wanted to take a little time to expand on the "Prototype 2" that Bojhan did. Mostly I just wanted to put a more visible example out there and show how this could potentially work from my perspective. Not pushing solutions, but I had done the visualization work, so I thought I should share it.
The first example is a simple node/%node page update to include the author of the node, and get access to the user blocks.
http://www.youtube.com/watch?v=dtO3QabRl6U
Source Doc: https://www.dropbox.com/s/ws139yngnkajw4o/component-ui-flow.fw.png
The second example is a bit more in depth. We add a language based data source from a relationship to the global user. We also add a View as a context that consumes a term and a language data source in order to provide a view of something by term by language. Views like these already exist in D6 and D7 (though they're sort of a seriously hidden gem) and they allow us to place components of the view in various panel panes (say pager here, header there, results elsewhere...).
http://www.youtube.com/watch?v=sEtUEgx7NbQ
Source Doc: https://www.dropbox.com/s/nu5z3nrbm48tahw/complex-context-ui-flow.png
These are all fireworks pngs, so I've provided them as well for anyone who wants to extend this work and run with it.
i'm wondering, if it would be
i'm wondering, if it would be possible to use an approach similar to the data selector that comes with the rules module.
my thinking is, instead of having to specify all contexts and relationships in advance, this might allow for adding any block and then configure it's required/optional contexts. the ajax data selector offers possible contexts and creates the required relationships "on-the-fly".
itangalo has a screen cast that explains data selectors (skip to 4:15)
http://dev.nodeone.se/en/data-types-and-data-selection
i believe using such dynamic data selectors for defining contexts when they are needed might be a more efficient approach. am i missing any conceptual requirements that force us define the contexts in advance (from a ui perspective)?
I think that would make the
I think that would make the available contexts rather abstract and harder long term for end users to grasp, but that's just my opinion. I'm not a fan of Rule's style data selectors. The component is really nifty, but it has it's own technical baggage and weight. I think you're just substituting one odd technical thing for a a more abstractly represented version of the same concept. But that may just be me.
Eclipse
Based on having used Rules
Based on having used Rules and its data selector a lot, and also met a lot of people struggling to learn Rules, I have the following comments:
I would like data selectors in Blocks&Layouts for D8, and I think it should be investigated. But it shouldn't be a blocker for Blocks&Layouts as a whole.
thanks for the comments
thanks for the comments EclipseGc and itangalo!
i understand that data selectors have some drawbacks with their current UX and that they might not be able to cover all possible cases.
what i really like about them is that they allow to reference on-demand and traverse along relationships in a super-fast way. it's basically one click per relationship. using the "standard" panels/page manager mechanism have to define all contexts before-hand but of course you have more options.
Good videos
Great videos -- they summarize the relevant parts of existing Panels workflow well.
One comment:
I don't think it's a great idea to have tabs based on the data sources that components consume, i.e. having all components consuming a "node" data source being gathered on a tab called "node". This is for two reasons:
1. Ellie is probably looking for a tab "front page components" or so, not "static components" or "language components". Site builders may think in terms of data sources, but Ellie probably doesn't.
2. There will be components that consume more than one data source. (One example would be a view listing forum topics by user, taking both a taxonomy term and a user as data source.) Adding a tab "term and user" seems like an ugly path.
Instead of using data sources as categories, I'd prefer the way i.e. Mini Panels does it today, where you can specify category name manually.
To be hones, though, I'm not very fond of tabs for browsing components. In Panels, the tabs forces me to look in several different places before I find what I'm looking for since I don't always know what category a new block uses. The Views approach (massive list plus filtering) is more usable, imho.
"add data source" -> "use data source"
When clicking through prototype 2 (again!) I finally understand the "add data source" part. Previously I interpreted it as adding new data sources to the block you're setting up -- but it's actually just using/calling any of the data sources already available.
I like this approach, not least because it makes it (theoretically) possible to preview components before placing them. When adding "acting user" as a data source, the component "user e-mail" could actually show something.
I'd like to suggest one change, though: I'd like the component list to show all components, but have i.e. "user e-mail" greyed out with a message "requires a 'user' data source".
Listing all components gives (imho) a shorter path to finding and adding even the complex components. Also, a "requires a 'user' data source" message could hopefully be a small aid in learning how to add that component.
Another idea: Maybe this "requires a 'user' data source" could be used as a link to add a user data source? (There could of course be components that consume more than one data source, which should be taken into account when building such links. But one step at a time.)
Also, as an aside to all of
Also, as an aside to all of this, one of my other concerns is that the data sources we build ,from whichever process, are used outside of just blocks. They're also used in conditional plugins that determine things like "Which node->type is this" so that one node bundle can have a different layout than another.
Also, in my approach I've tried to preserve some level of clarity on how data sources are related to each other, and webchick & bojhan's suggestions will be far more abstract in this regard.
Eclipse
you should definitely check
you should definitely check out the videos posted by itangalo
as always, he walks you through the ideas in a very clear way
http://groups.drupal.org/node/227543#comment-752358
Very kind
Thank you, that's very kind. :-)
Copy wordpress sidebar system
I somehow ended up here... 2 cents, copy wordpress. It works like a charm for assigning content to the sidebar.
The WP interface seems to work well for me. Why re-create the wheel when the wheel is already working?
Web Dev, Consulting and Design
DynamicDan.com
Graphic notation system for showing component configuration
I’ve just scanned over the discussion again to see where we’re at on the ‘select context first’ vs. ‘select content first’ question. I share the concern that asking a user to select a ‘context’ will make for a difficult UX if they do not have training. Over the last few weeks I’ve been exploring ways to ‘prove’ that we can have a ‘content-first’ approach and still satisfy the technical needs that Eclipse is concerned about.
So far that exercise has lead me to producing a somewhat hefty document (50 pages) that attempts to put this problem into the perspective of an ‘outside-in’ interaction strategy. As big as that document is, I find it is still missing some important elements – at least in terms of addressing the full range of possible scenarios. I wish I had more time to spend on this and clarify my position but other commitments are preventing that at the moment.
However one thing I do want to share right now is the graphic notation system I devised for describing and discussing contextual component configurations. I’ve prepared a video (about 11 minutes) to walk through it. My hope is that this notation system (assuming it does reflect the reality of things) could be useful in these types of discussions. The notation system could certainly be tightened up a bit more (especially in the area of describing field level outputs) but I think it’s probably good enough for now. Click to see Video
Meanwhile I’ll try to fill in some of the gaps of that analysis document and then break it out into more digestible parts.
Michael Keara
User Interface Systems Architect,
The User Advocate Group
Great visibility UI
I really like the graphical representation of visibility conditions.
Context overloaded?
Here, and in your video, you define Context.
I know Larry Garfield, in the WSCCI initiative, is also using the word Context.
Is the definition of Context the same in both initiatives?
If not, we have a serious name collision problem. One or the other initiative may need another word.
Is there really a "node from URL" data source?
I'm confused that a lot of the examples here mention "Node from URL" as a data source. As I've understood this initiative, every (populated) layout should be reusable at other places on the site. That is, if you build a layout for showing articles, you should be able to use that at the main content of "node/%node" as well as in the sidebar at "my-path".
As I've understood it, so far, this means that pages and their content are technically separate from each other. You have a "page handler" (or something) listening to "node/%node" with the additional condition that %node->type is article, and this page handler in turn calls a block "my article layout". This block could be called by other page handlers too, and can be used as a component to build other (populated) layouts.
If I'm right about this, it means that the (populated) layout can't know if a node is fetched from the URL, and shouldn't give a damn about it. It gets a node as input, and responds by building the article layout based on that node.
When called by "node/%node", the node from URL is sent into the layout. When called from "my-path", it could be fed NID 3 or some other data source available to the caller.
If I'm wrong in this I'd like to know pretty soon, since I think it's pretty crucial. (Anyone?)
it's a good distinction.
it's a good distinction. certainly in Panels right now, there are two discrete types of plugins - arguments and contexts - that fulfill the pattern. the context plugin are the only thing that are an actual data source; arguments are simply logic to map incoming information to a context. so...
is absolutely right. the actual place from which a "data source" originates should be immaterial to the layout/thing doing rendering based on that data. (if it's not, we're doing this all wrong.)
i think this might actually point to the chief problem with the terminology Kris has been going after - the way i initially wanted to write the preceding paragraph was, "Data sources have nothing to do with the source of the data." The big goal of contexts/data sources is to be a bundle of consumable data that's abstracted from the actual source ...but actually calling them "data sources" is unfortunately rather ambiguous in that it could just as easily be referring to the originator of the data as it could to the abstracted data sitting in the pool. yikes.
Hmmm... duly noted. I was
Hmmm... duly noted. I was trying to express that this was a source from which data could be extracted and used... nothing to do with where that source came from. I'm fine with adopting a different terminology, this one seemed to have some traction though, so I ran with it. Suggestions welcome :-)
Eclipse
Contexts
I think contexts is the right terminology. There are several possible concurrent data contexts that can be thought of:
The author, the currently logged in user, the url parameters or arguements, the browsers capabilities, blocks configured for the url path.
I'm not suggesting that all of these need to be selectable entities, but if we start thinking about data contexts as just data that gets populated from something, I think the UI can derive nicely from that.
I guess the thing I'm saying is that URL arguements can just be thought of as another data context.
We have previously called
We have previously called them contexts (for many many years now) and found it to be a somewhat confusing notation for our user base. That is why we are trying to move away from it.
The evolving definition - from abstract to tangible
I just want to simultaneously respond to two branches here - batsonjay's question about the meaning of the word 'context' and itangalo's question about data sources in URLs.
The short answer the batsonjay's question is 'yes': my intent is to refer to the same thing that Crell's discussions are talking about - that is the underlying data structures that can be used to drive specific content retrieval mechanisms so that the right stuff appears on a web page at the right time.
The meaning of the word is crucial and the question is worth re-asking as things are defined throughout these discussions. Back in Drupalcon Denver, our Bof uncovered many uses of the term ‘context’ and this ambiguity was recognized as a problem for our process.
The devil of it is that the meaning of the word ‘context’ can vary depending on the context in which it’s used. Here’s my latest take on that problem.
From a UX design point of view, I strongly believe that using the word ‘context’ in the language of the user interface will be a significant showstopper. We would have little control or influence over how each user will understand the word so it’s likely to cause a lot of confusion.
Instead, I’m hoping we can find ways to guide the user to work with more tangible things that they can understand. For example, I think we will have more success if the user is presented with choices of types of ‘components’ and can build pages with ‘real’ things like that, as opposed to abstractions such as ‘contexts’.
As I see it, the term ‘data sources’ is an improvement, albeit not perfect (see Itangalo’s comments in the branch below). But a data source can be resolved to something quite concrete – according to EclipseGc (and as I describe in my video) it can be one of three types of things: a path (argument); an explicitly defined parameter (custom context); or another component (relationship). I’m not saying we should use the term ‘data source’ in the UI either, but conceptually I think it takes us further along the path we need to go down.
I think a usable UI would allow the user to build things in a Lego-like fashion where fundamental decisions can be made based on the general intent of a page (more on that here). This initial level of page building decisions would determine how many layouts would be required for a given page and what the conditions are for activating each of those layouts. But this initial step still deals only with the basic ‘mechanics’ of layouts and layout selection. Following that would be decisions around what should be in each layout. At this level I believe we could have a UI that allows users to assemble component relationships in a building block fashion that they can easily understand.
I don’t believe such an interaction strategy is possible if we fail to convert abstract ‘contexts’ into tangible pieces that the user can understand and work with.
All this leads me to the belief that using an ambiguous URL structure such as ‘node/%node’ sets up a significant usability roadblock. The practice of extracting meanings about the type of page (and hence layout structure) from such implicit contextual data forces the user to think in very abstract terms and that’s where the confusion is bound to arise. We have an opportunity to explore an alternative approach that is based on tangible, 'intention-oriented' page management principles.
Michael Keara
User Interface Systems Architect,
The User Advocate Group
Just to clarify – I don't
Just to clarify – I don't think data sources is a bad term. It's certainly not perfect, since (quote) "data sources have nothing to do with the source of the data", but still…
Two other candidate terms might be arguments or parameters, which I think would make sense to coders (but not to many others).
Adding a small image which might help clarify the necessary middle step with a page/path handler. Or something.
I wanted to let everyone
I wanted to let everyone know, that we have taken all the input of this thread into a new one. Where we present the prototypes we have been working on. We know we might not address all concerns but we also need to keep moving before D8 feature freeze hits.
http://groups.drupal.org/node/242403