Context UX – use cases

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

(After two hour skype call with Larry discussing Pages and Components, we came up with these use cases to do UI sketches for)

  • "Here's an admin form for configuring a view for this" *

For the DX in providing admin UI for all this, this means coding/configuring the response rules for a given path. Where response rules boils down to providing forms that let people do such things as:

  1. I want a request to node/nid/history (with request type HTML) to be a list of teasers of the revisions of that node (nid).

  2. I want to configure a request at foo/bar, request type JSON, to return the 3 most recent node titles, as JSON. Then I want to set up another request at foo/bar, request type Atom, that return the same 3 titles, but as ATOM/XML.

  3. I want a full Page layout specifically for nodes of type Event. I will drag and drop the Event-pieces into place and add any other stuff that needs to be on this kind of page. (from header, footer to related content block, etc.)

  4. I want to configure nodes of type News to have a different layout, without configuring individual fields. "Just show me the full view of a single node." [This means "return the full node view mode, no reordering of fields", correct?]

  5. I want a landing page layout for different site sections. The layout is the same across the sections, but the content shown in is context-dependent. [This means "always teasers in main column, always recent comments in top-right corner", correct? Not "there is always a main column and a top-right corner, and the context should decide what kind of elements are used there".]

  6. I want a Product node to have a different layout based on the section it is in.

  7. Now, give me a single unique page so that I have a homepage I can keep tweaking without messing up other pages.

  8. I want to configure a per-user dashboard, that each user can customize. Now, make it so that: user/id/history is a page accessible to all. Anonymous role can see it and user/id/dashboard is only accessible to user. [Content of user/id/history is not relevant, right?]

  9. I want path X/Y/Z returns a redirect to another page based on a selected rule (redirect module).

If choosing just one, we should focus on 'News content items look like this, Event content items look like that'.

(Oh and BTW, this kind of logic should be made available to other roles than user/1. How do we arrange for setting it up that a group manager can tweak content flow and page layout for her group only? So that she can define that a Forum post node shows titles of 3 related posts in this group)


Sketching out the UX for

yoroy's picture

Sketching out the UX for these will inform some base architectural decisions that need to get made sometime. Design the right limitations into the system that gives us a UI model that can be made comprehensible by mere humans etc.

Nine is a bit much, so some sort of grouping or prioritizing into 3 main stories seems desirable, but lets not impose that beforehand, but rather arrive at them while exploring this spectrum.

More as the story develops… :)

Cool stuff

Itangalo's picture

Looking forward to reading more, and hopefully sketiching some ideas on physical paper.

I added three questions [in brackets] in the wiki page, where I had problems understanding the text fully.

Great work taking this forward.

Correcting story

Crell's picture

I made a small but critical correction to story 2. The important factor is that the same URL with different request types returns different things.

Moving towards an interaction strategy

User Advocate's picture

A nice set of use cases. After having spent a few months lurking in the background and trying to catch up on the various core context discussions, I'd like to jump in and offer some immediate responses to these use cases. But before I do that I want to point out that, in my opinion, the key factor here is the way in which we understand what is meant and implied by 'given path'. This leads directly into a concept that I refer to as IA Space (Information Architecture Space).

By IA Space I mean the virtual space that is created as a product (or by-product) of defining url paths. These can be conceived of clearly and simply and intentionally (e.g. I've seen clients define such spaces by sketching a vision of their site organization on a napkin.) Such intentionally designed spaces can be used as the basis for a 'pull' model - which is the opposite to the rather haphazard spaces formed by Drupal's current 'push' model. An IA Space is a concept that can map directly to a UI that supports a 'Page Management' Role. (For more on what I mean by 'Roles' go here (a video) or here (an article).)

So here are my (rather stream of consciousness) responses to each scenario along with various questions that arise for me. I begin each section with a paraphrased restatement of the scenario as I understand it. I apologize in advance for any overly abstract verbiage. For the moment I want to simply capture my thoughts and then later explain in more detail - and make some pictures!

#1 Get a history of a node's revisions as a set of teasers. Touches on the concept of a 'content source' which is different from actual end user consumable content. The thing that provides the list of node titles is the content source. The titles are consumable content. This doesn't sound too extraordinary because we use content sources like this all the time (e.g. views).

But as an aside - on a higher level UX design perspective this particular scenario raises questions for me: will this notion really be meaningful? What if the changes all happen below the teaser cut off? (Contrast this to 'check in' comment histories and/or diffs for code revisions)

#2 Two paths (or one) with the same data (3 node titles) requested in 2 forms (JSON and XML) Following up from the previous remarks, this requires a clear separation of the concepts of content source (a formal mechanism for somehow retrieving content), content placement (layout) and content output (the consumable stuff). But at a minimum, placement happens as a function of both layout selection and IA Space location. Presumably additional contextual conditions may also be applied (i.e. path is not the only contextual determinant.)

Let's think more about content sources - a content source is a key concept behind all these discussions. It is indicative of the subtle nature of the core context UI problem – that there is a middle ground between form and content – dynamic content generators/derivatives such as views and the various response mechanisms envisioned in the WSCCI discussions are not end user content but sources of end user content. This leads to the UX dilemma of representation in an admin UI. E.g. are we showing the name of the view or the output of the view to the given user. Different user Roles will probably want different representations.

But (given Crell's correction) the point of this scenario is that the response can return different forms of data and hence the UI must be able to allow specification of the desired form. The trick of course is to associate each flavour of the request with other contextual factors and that association must be readily apparent to the user playing that Role. A key question here is which Role? Three contenders that come to mind are a Page Manager, a Layout Manager and a Content Manager. Deciding which Role(s) require the capability to specify type of data formats sounds more strategic than tactical and that seems to align more with either Page Manager or Layout Manager. Further scenarios would be useful to clarify the requirements on this. (more on those 2 roles in the next section)

#3 Full page layout for a specific node type (Event). Drag and drop Event pieces into place. Add other elements to enhance the page. This is a scenario for a Layout Manager Role - which as I just mentioned is not the same Role as Page Manager. I see the Layout Manager Role as being responsible for more artful manipulations of data than the Page Manager who I see as being focused on strategic IA Space page definitions.

But this is also a scenario that reveals the transition from page=node (the past) to a page=defined-containment-space-for-who-knows-what (the future). Love that. The key word seems to be 'pieces' – implying that the draggable items are elements pulled from the node rather than the entire node pushed out. This means that the node has gone beyond being just final content but can act as a content source – similar to a view. Very interesting. (I know this is done through Panels already but the Core Context discussions amplify this as a key concept.)

#4 Be able to show a node through a 'natural presentation' (to coin a phrase). Similar to the OO concept of a base class as distinct from a derived class. Crell describes the idea of blocks being able to build and render themselves (even as nested blocks). This implies a degree of autonomous behaviour on the part of such container objects. Could this autonomy extend to nodes? Are nodes of the future true objects in the same sense? Or will it always be necessary to have some external agent responsible for rendering? I'm not yet clear on what is being envisioned or implied by the technical discussions. I need to catch up here.

#5 A (common) landing page layout for different sections. The defined layout is applied to various locations within an IA Space. This amplifies the need for a well-defined page manager UI that supports the Page Manager Role whose tasks include defining the paths and applying various meaningful attributes to the items (path locations). In terms of page management UX, the layout is an attribute assigned to one or more paths. This assignment is probably done explicitly rather than algorithmically. That is to say, the layout is assigned to an explicitly selected group of paths. If this is a valid approach the emphasis of the UX problem shifts to the task of subset selection - the overall Page Manager UI may ultimately require additional helper techniques for assisting with the act of selecting particular sets of pages - but that's a separate discussion.

#6 A given node type (Product) is presented through a variety of layouts, depending upon the section (path). Cool, this almost seems to contradict the previous requirement. Thinking this through ... if the Page Manager is able to support assigned layouts for specific locations in the IA Space, then this requirement implies that there is an additional dimension of control at the point of those assignments. In other words, on the surface, it sounds like there might be an association between layouts and content types at this juncture. Presumably this association would default to an 'all' condition (automatically kicking in – in similar way to the 'natural presentation' of point 4). But intentionally applied exceptions could be applied by the Page Manager Role where needed. This sounds like a classic 'override' technique. The UI would have to represent such overrides in a clear way so they don't get lost or buried. Sounds like a solvable problem.

#7 A single unique page serving as a home page – decoupled from the 'flavouring' applied to other page locations. Once again, the concept of a Page Manager UI based on a clear understanding of IA Space seems to be useful here. Conceptually, the required attribute assignment strategy is essentially similar to the overrides mentioned in point 6.

#8 Mix of access rules/plans – some locations are private to a given user and some are public to all. (The implication is that there may also emerge a future requirement to assign semi-public access to specific user groups – but that's another story for now.) In the example given, the two paths are siblings rather than 'parent/child' – user/id/history is 'next to' user/id/dashboard. This is good since it means that the non-owner user does not have to pass through private property to get to the public place. Again, on the surface, it sounds like an attribute assigned to a given IA Space location in the same way that we described layout assignments in point 5.

#9 Path x/y/z redirects to a/b/c based on some rule. Suggests a sort of 'smart page' concept where the rules are additional intelligence bestowed upon a given page. Nice concept. Perhaps more than all the other cases mentioned, this reveals the challenge of how to represent attributes of pages (IA Space locations) in a way that is not overwhelming to the user playing the Page Manager Role. Again, not entirely unsolvable but certainly it will benefit from well-defined interaction strategies based on nice, crisp metaphors.

So I'd like to suggest that I think a lot of benefit could be gained by thinking through the concept of IA Space and using that as a nice, crisp metaphor to underpin an interaction strategy that can support all of these scenarios. There are some deep questions to resolve such as how to reconcile the two methods of path definition - the internal method where paths are defined by code and the external method where they are defined by an administrative interface (roughly corresponding to Panels Page Manager's system and custom pages). Looking forward to digging into that. :)


Michael Keara
User Interface Systems Architect, Myplanet Digital

Michael Keara
User Interface Systems Architect,
The User Advocate Group

Use cases?

xtfer's picture

Is it worth rephrasing these as use cases in addition to the user stories? User stories can sometimes mix ideas, for example #5 and #7 could be the same set of use cases (and please excuse any terminology which doesn't match with current discussions)...

  • A user can create a page/IA space with containers for other site objects
  • A user can assign this page to a URL/s
  • A user can assign this page to menu item/s
  • A user can choose which contexts to apply to the page
  • A user can choose the layout of the page

(which sounds like Panels, predictably)

Very worth it because they

yoroy's picture

Very worth it because they are simple and short and to the point :)
People should feel free to update the original wiki, xtfer's one-liners seem like good headings for summarizing Michaels feedback?
Awesome feedback so far, keep it up!

Required viewing

yoroy's picture

How timely, Swentel just posted this:

A screencast of the "Page manager existing pages" module which allows you to override any Drupal path and panelize it.
Short and useful overview of what we're talking about here, shown in the way that it works now.

(and a good example of why we're redesigning the modules page ;-)

Defining 'pages'

User Advocate's picture

The timing of swentel's module/video is indeed remarkable. Very exciting to see this exploration into squeezing more out of the Page Manager concept.

I'd like to clarify a bit more about how I understand 'pages' because the way in which we define 'page' seems critical to making sense of a core context architecture and a new UX vision.

Unfortunately the word invokes strong associations with physical (paper) documents and this reflects the way in which the web, as a content delivery mechanism, has been perceived since its inception. The legacy of this perception has caused Drupal architecture to be heavily based on the assumption that a page is a single node (with optional bits in the periphery). But the implication of a core context architecture is that a radically new way of perceiving the web is now possible. So much so, that the word 'page' seems entirely inadequate.

This is why I wanted to introduce the notion of 'IA Space' – to help provide a means of talking about a web site structure without having to use the word 'page' and the associated baggage that comes with it.

To me the elephant in the room is that pages are essentially IA Space locations and that these are defined entirely by unique urls. This implies that a 'Page Manager' should somehow, by definition, always deal with the entire set of pages/urls/locations that define the addressable 'shape' of a web site.

This concept seems to be supported by the contents (and existence) of the menu router table which seems to describe precisely this. The very fact that all this data about a web site's defined paths is collected and stored via the hook_menu command is, I think, worth noting. I can't say for sure but I expect that some of the developers' dissatisfaction with the current architecture is that the menu_router holds everything back to the traditional page model and thus limits the ways in which content can be specified, packaged and delivered. If that is the case then the concept of IA Space might be a way of being free of that legacy while still retaining a systematic way of identifying content sources.

Is this a valid interpretation of the word 'page'? Is it possible that a fully matured Page Manager might be a mechanism for managing all of these IA Space locations?

One last thought – aside from technical realities, it may be that we have mixed feelings about anticipated UX for such an all-encompassing type of a Page Manager. Perhaps we might intuitively feel that such a large set of urls might be somehow unmanageable, or that managing the addressable spaces of a web site in this way is somehow restrictive. These are valid concerns and I think they should be explored more fully. However I do believe they can be addressed with the right interaction strategy.

Michael Keara
User Interface Systems Architect,
The User Advocate Group

Key distinction

Crell's picture

Very interesting writeups!

I agree that "page" is a misleading word, as it implies a much smaller use case. Let me combine that with a reply to your larger response above.

I like the way you split "Page Manager", "Layout Manager", and "Content Manager". However, I'd take that a step further. As background, one idea I discussed with yoroy is retaining a split between "page layout" (of which we currently have one, page.tpl.php, and no GUI other than Panels Everywhere) and "content layout" (which is currently whatever is in $content, and for which we have Panels/Page Manager). That way, we can still have a concept of "sections" that apply to the page layout while content types, specific pages, or even specific entities could control that inner layout.

However, there is also the non-HTML-page factor, as you note. Drupal in this model is not delivering "pages". It's delivering responses. Those responses will sometimes be JSON, sometimes be Atom, sometimes be a full HTML page, and sometimes be an HTML fragment. As story #2 suggests, those could live at the same path, but separated by some other aspect of the request.

So I'd suggest that there are 4 layers of role/access:

  • Response Manager (defines what request/context information maps to what controller, such as path, accept header, organic group, etc.)
  • Page Layout Manager (defines the layout of a frame for HTML-page responses, which is only a subset of requests)
  • Content Layout Manager (defines the layout of the content of an HTML-page response, which is only a subset of requests)
  • Content Manager (defines the content on the site; creating nodes, curating nodes, managing nodequeues, etc.)

In that sense, "page" is only a subset of the UX problem space.

Issues with frame and content terminology

effulgentsia's picture

Great discussion here. Generally, I like where it's going. Just some minor nits:

defines the layout of a frame for HTML-page responses

Let's please not use the word "frame", as that has its baggage from browsers/HTML (framesets, iframes) that I don't think we want to confuse with. Assuming we continue with the existing Drupal core word of "block" (even if it becomes closer to a Panels pane than a D7 core block), I think we can say "defines the layout of blocks for an HTML-page response".

defines the layout of the content of an HTML-page response

I'm not yet clear on how far towards the Panels Everywhere vision we'll be able to get in D8 core. But, if we get sufficiently far, then the concept of "the content of a page" becomes nearly meaningless. Pages won't have content. Only blocks will have content. And potentially only some types of blocks (e.g., a block that shows an entity, or a list or entities). So we'll need to decide whether to build the UI around the idea of "defines the layout of content within a block" or around the idea of "defines the layout of content within an entity". Field UI and Display Suite are essentially the latter model. The former model is appealing, but might need to be very block-type-specific, so that we can have a "entity layout manager" (Field UI / Display Suite), a "list of entities layout manager" (Views), etc.


yoroy's picture

It seems to me that 'has URL' ( has system path) is THE defining characteristic of what is a Page. At the most abstract level I now see it as: a system path is a place (Page) where if you go there, you fire off a request. When you get there, you see the response. All the variants that happen based on the path, user permissions and all the other context bits make up what you call an IA space, right?

Locations, spaces and more food for thought

User Advocate's picture

@yoroy that's almost what I mean :) I see IA Space as a name for the sum total of all paths defined for a site – system paths, custom paths, whatever. Put anther way - it's the union of all such paths and hence makes a sort of 'shape' that defines all the places one could visit in a web site.

Think of these places as being like real physical places – one analogy is, say, restaurants. Let's say a given 'Restaurant Space' is the union of all restaurants in my city. These are defined locations - just like urls. What takes place in those restaurants – which for a 'user' is largely about the eating experience but could also be seen as an environmental experience - is dependent on various other contextual conditions, beyond the location. One key condition is time – if you visit the location in the morning the 'contents' (or response) is breakfast. If you visit in the evening, the response is dinner. Other contextual conditions can apply also – if my personal needs can be factored in, then my dinner plate will have my favourite food on it, say chicken, which is different from the response to my vegetarian friend who sees fish on her plate.

My individual experience of a given location (restaurant) is highly dependent on these various conditions that come into effect when I go to that specific place. The variations in my experiences (and those of other visitors) on different visits are a result of the activation of 'variants' - the specific responses that each restaurant is set up to provide to each customer.

@crell With regards to the distinction between page layout and content layout would it make sense to use the terms 'presentation layout' and 'content assemblage'? Just throwing that out there as a way of moving further away from the use of 'page' and making a more defined separation between the formal (layout) and the content related aspect.

With regards to presentation layout, it's interesting to contemplate how chain restaurants provide identical 'brand responses' in terms of physical environment experience. This seems to map nicely to the concept of 'sections' that might use their own presentation schemes for their IA Space locations (AKA section pages).

(BTW Larry, I think the layers you suggested make sense - I want to mull that over a bit more.)

One thing I find that can be tricky when talking about this stuff, is being clear about the difference between the user experience of a page/location and the 'programmed' conditions that affect that experience. The more precise we can be the better. I think analogies can help sharpen the understanding and language but they do ultimately get a bit fuzzy at the edges. One can use lots of different analogies for this concept. In the Panels UX Review videos (that I will be posting next Monday) I use a different analogy – that of a landscape. But I'll save the details for the video viewing! :)

Hope this helps,


Michael Keara
User Interface Systems Architect,
The User Advocate Group

Panels UX Review

User Advocate's picture

I've just put up a post regarding the Panels and Page Manager usability review that I've been working on at Myplanet over the last few months.

The review is not exhaustive because there is so much ground to cover in the Panels module suite. But I do hit on some fundamental points related to interaction strategy and general usability issues. I think some of these points may be of interest to readers of this thread.

In the blog post I've presented a set of 5 videos that summarize the project and my findings as well as suggest possible improvements. The last video is somewhat speculative and delves into an alternate strategy for In Place Editing. Very broad brush strokes but perhaps worth considering.

Michael Keara
User Interface Systems Architect,
The User Advocate Group

So, I suppose it's time to

EclipseGc's picture

So, I suppose it's time to weigh in here. I've been working within this space very heavily for the last 3+ years. I co-maintain ctools, and specifically contribute a lot to the page_manager submodule of ctools, and maintain my own administration toolset based on page_manager, so I'd like to think I have some perspective on this topic.

First, I'd like to comment on something effulgentsia said.

... if we get sufficiently far, then the concept of "the content of a page" becomes nearly meaningless. Pages won't have content. Only blocks will have content.

This is essentially the correct perspective. Pages will have content in that certain pages are defined with certain content, but there should (ultimately) be nothing that prevents you from ripping that content out and completely replacing it. Drupal core itself no longer cares about what should be appearing on a given page because that's completely configurable.

I've been giving this a lot of thought in relation to core itself lately, and I have yet to actually run it fully past ANYONE, but here it goes:

Content Management:

This actually isn't a thing except as that phrase relates to "CMS". It doesn't actually relate to what's displayed on the page because, as effulgentsia so aptly put it, that's meaningless. I've said this a few times here and there, but what's really happening at this level is that blocks are your basic unit of output. All blocks aren't content, but all content is a block. The same should be true for administrative output as well, any form should have a block wrapper for display purposes.

This means we need to put a LOT of thought and effort into the block layer, because we're essentially betting the farm on it. No we probably won't be locked into that, but if we go this route, all of core should utilize it at this level, and that means a LOT of work. Every form, every block, every notion of output the system currently has (for html) needs to be "blockified". The contents of these blocks will need to be informed by the context of the page (what node are we on, who's the current global user, what node/term/user/entity references does this node have access to, what's the title of the node so that I can pass it to a search query to get similar content, etc, etc, etc). This is not a small task, but it is worth while. I've rebuilt a lot of these components at various times and many are close to being generic and just need that extra 20% of effort to get them there. A strong consistent wrapper at this level is also a big big plus (which plugins is buying us, but that's another topic).

Response Management:

This is the fundamentally newish stuff for drupal as a whole, the other two components here have already existed in fairly extensively used patterns in contrib, but this is sort of a middle space between ctools page_manager and services modules. We're essentially needing to have a responder layer that figures out what to do (via certain criteria) and then have a staged response to it based on that. In a lot of ways I see this mapping to modern day page_manager very heavily in that the header information for things like application/json or text/html etc are really what we think of as "selection criteria" or "access". This is a system where by, depending on what we have available in our context we can route a completely different response. Is this user a member of a particular role? great they get this response (we call them variants) is the node type we're on an image? great give this response. It's just we need an extra layer of this above where it would normally exist in page_manager, and it needs to be ultra focused on the sort of responses that we care about from a services perspective (i.e. perhaps ALL it cares about is the request oject itself and none of the associated drupal specific contexts). Also things like 301 redirects and such should probably live at this level, even if they're fulfilled at a different level.

Response Fulfillment:

This is essentially the "layout" layer, though it can do much much much more. The problem here is that this is one of the areas where we've had especially large amounts of user confusion because there are so many things you have to understand at this level to get what you want. And it goes beyond just picking content. The responses (variants) I mentioned in the previous layer actually live here, and you really have no recourse (if you want to support this, which really... you do) except to order the responses manually. Example: When someone visits node/1 and we want to customize the layout by node type, all node type checks live at the same level. So if you build a "user 1" specific layout and put that after all the node type specific layouts, it will NEVER load because some other variant matches the criteria first. Also understand this is an area where you can see a performance hit (which is why I suggested a totally separate level of this at the response layer to minimize this for non html responses fulfillment).

These details go on and on, but we should also probably have a parallel administration for the various "Content Type" headers we want to support. So for json, even if we're using the exact same paths, a separate json specific administration section might be advisable (because we don't want so many variants all stacked in the middle of each other for all of this). Also, this would give us some benefits in that we might be able to do things like provide "Content Type" header specific utilities. For instance, if I want to json_encode a node across a specific url that's a VERY different utility from doing a "node view". These details go on and on.

Actual UI:

This is of course where things get really hairy, because having used panels like architecture for a long time know, I know that not every custom "gets" this. And so we'll need some extra layers of simplification that can be built by site builders. This is probably a layer where we specific (by permission or role or something) that various users have access to configure various layouts, individual nodes of type X, or whatever with ONLY the content that we've exposed to them. And the kicker there is that it all changes based on the context of the page anyway so... yeah. Also, coming up with sane defaults is a really good idea. I think the new panelizer module has got a LOT of things right in terms of workflow, I'd love to see something similar to that for D8. Essentially my goal is something that looks like a mixture of panelizer and panels everywhere with a super block interface that gives us a completely plastic interface that we can rearrange on demand. I think this is legitimately achievable, we just all need to hop to it. :-D


Super Blocks FTW

jgj's picture

This is a fantastic summary. As I read it, all of the little ideas I've had for how Drupal could work over the years start bubbling to the forefront. The idea of the block as the basic unit of Drupal output is, to me, a natural progression from what Drupal is now in Drupal 7, to what a RESTful Drupal could be in Drupal 8.

Your description of "blockifying" every notion of output is right on. I'd like to take it a step further by offering two possible features of these super blocks that would make the paradigm of a page response in Drupal (and the UX we can offer those working with said responses in the UI) something to behold.

  1. Blocks *have* layout. Rather than relying on layout being a separate layer in the response stack, why not build it in directly in the block? That way, each block can be responsible for laying out it's own content. This opens up the possibility of users being able to much more simply and transparently modify the markup and styling for a given block. And it works perfectly if...
  2. Blocks can contain other blocks. Now we can conceptualize every single piece in a Drupal page response as being part of an array (or cascade) of blocks.

Additionally, we know that a context object will be available in requests and responses, so why not make some subset or offset of that contextual data be available/inherent to every block. Blocks wrap and render content/controls (Data). Blocks understand, modify, and pass along Context. Blocks have and implement Layout.

To do something like this I think we need strong standards for what Data coming from Drupal's REST interface looks like and what its structure means. If blocks know what kind of data they are holding, their self-contained layout implementations not only become better suited, but can be easily swapped out in UI with other layout implementations that match the data type. In the same way, I think we benefit from some non-scripty way to encapsulate layout logic so that it can be passed around and swapped in or out, and modified granularly as a last resort (or first, if you dont know anything but HTML and CSS). Basically, block-contained layouts are sort of like theme functions. Their definitions exist outside of the block itself, but the block contains the implementation (or some strong reference to it) so that it can render its contents appropriately.

In my mind it's abstractly reminiscent of the DOM itself. Like HTML tags, each block becomes a wrapper for some renderable data and/or other blocks. Just like an HTML tag can contain text and/or more HTML tags. The analogy maps like so:

<blocktype id="foo" class="bar">This is a section! <a href="#">This is a link</a></section>
               ^           ^           ^                ^---------------------^
           unique id     context    content (text)      content (another block)

Hopefully this all makes sense to someone other than me. I'd love to hear what people think and, additionally, I'd love to help out in any way I can moving forward.

See the Layouts initiative

tkoleary's picture

Your comments are all perfectly to the point and map very closely what is being done in the blocks and layouts everywhere initiative which was recently split off from this initiative and is being led by Kris Vanderwater (EclipseGc) see his pot on it here:

We would love your help on this. Feel free to contact me, Kris or Jesse Beach.

Looking forward to in-room discussions

Itangalo's picture

This thread is, like previous ones, growing really long. A lot of good ideas, but it is difficult to keep them all in the head.
I'm really looking forward to DrupalCon Denver and the discussions that inevitably will take place there. I think meeting in person and talking about this – probably for quite a few hours – will be really useful.

A few days ago I saw Amazon posting a link to these videos, discussing UX revisions of Page manager and Panels:
Being a big fan of Page manager (and mostly Panels) myself, I reacted rather strongly when the video described Panels in-place editor as a "car crash" from a UX perspective. But when listening more, it makes perfect sense. I think the video content is useful for this discussion as well.

See you,
//Johan Falk, Sweden

EDIT: Just realized the videos were created by User Advocate, who is quite present in this thread. Thanks a bunch for the well-made analysis!

I'd much prefer to try and do

yoroy's picture

I'd much prefer to try and do some kind of virtual sketching sprint before. We'll be much more effective in Denver if we're already a bit more on the same page (hah!). More sketches, less words :)
Itangalo: it would be great if you could play along (you already did in previous ones :-).

I don't have any specific ideas yet, but lets try and work something out and plan for spending a couple of hours in parallel time working on things. Next monday we'll be having another UX open hours chat in IRC, we could use that to discuss and plan this a bit more.

A few examples of other CMSes

cosmicdreams's picture

I've seen the page building metaphor in Sitefinity before. I wanted to make sure you guys saw how they handle the problemset: (I've posted these in other threads) - page building (jump to 0:50 to get right into it.) - page building + user friendly UI (wysiwyg_fields has shown that this is feasible for Drupal)

Software Engineer @ The Nerdery

User stories generated from those videos

cosmicdreams's picture
  • As a site builder, I want to create custom layouts for pages or sections of pages that can be reused when I'm constructing a page.
  • As a site builder, I want to see how my page is going to look like when I click save before saving the page.
  • As a site builder, I want to control where a block is placed on the layout of a page.
  • As a site builder, I want to modify how an individual block appears.
  • As a developer, I want to create specialized formatters that control how a block appears to the user.
  • As a developer, I want to create a specialized layout the provides the set of regions that users can add blocks into.
  • As a developer, I want to create custom widgets that can be added to added to a page.
  • As a developer, I want to create custom widgets that can interact with other widgets on a page.
  • As a site builder, I want to place a sub-layout inside a layout so that I can place blocks inside that layout.

Software Engineer @ The Nerdery

Process suggestion

mikkopaltamaa's picture

Please note that a site builder never wants things like "create specialized formatters that control how a block appears to the user" and "custom widgets that can interact with other widgets on a page". The main problem with user stories is that they often describe the details of a certain implementation and then claims that users want it. Which is not correct.

Actually, this is what a site builder wants:

  • Create a site that looks just like the wireframes and/or layout images (which can be anything)

In addition, a site builder wants:

  • A tool set which make it as easy to accomplish the first item (may involve elegant data models, good default values, usable UIs etc.)

As a first step I suggest taking a set of complex real life site layout files as concrete examples. And after that, simply design a solution which makes it a pleasure to implement those. :-)

I think we all know how

neclimdul's picture

I think we all know how making a website works. We get wireframes, mockups and if we're lucky user stories and process diagrams. What these use cases chose to identify are specific pain points of site development and possible implementation hurdles we've identified from discussions. We need to narrow down from the free form discussions that have been raging and get real concepts we can start planing around.

If you need something outside what's listed, we need to identify it now or work around it during the release. Also, its not like we're breaking the tools of the language, you'll still be able to use PHP to do "anything". The point is, we're trying to identify how a specific part of the site building workflow works and how we can empower users implementing it.

The good thing about real

mikkopaltamaa's picture

The good thing about real life examples is that they often make the actual process clearer and easier to understand. They can also give better insight into what is really needed and what would be the best way to achieve it than some abstract speculations.

Of course, in real life the focus must be on choosing the most optimal and time-saving solution, which is also possible to do without too much work and without breaking all backward compatibility of Drupal. However, I personally like to check on what would be the most elegant way of doing a certain thing and then see how close I can get, given the restrictions of the old system and/or design.

And also, in this case there are so many "pain points" that just fixing them individually is not going to help much. In my opinion, a complete redesign should be done at some point.

For an exercise, let's say you need to build a very simple news site. It has 4 different page layouts:

  • Frontpage (about text, latest news)

  • News (news list)

    • News item (multiple pages; title, images, body text, comments etc.)
  • Search results (result list)

Now, as a site builder, you should be able to change the layout of each of these pages individually of each other. The simplified process could be as follows:

  1. Create the pages of the site

  2. Set up page layouts for each page

    2.1 Create containers for content items

    2.2 Arrange containers into right order

    2.3 Define the grid settings for each container

  3. Create the content types (news item)

  4. Create some content items (sample news items, copytext blocks etc.)

  5. Choose where the content items are displayed

Lets investigate each of those items more closely:

Item 1: Create the pages of the site

Probably the easiest way to accomplish item 1 would be to offer some kind of site structure section for site builders, from which you could create these pages and later choose any of them for further editing. Quite a many of content management systems offer this kind of feature, but unfortunately Drupal does not.

But let's assume there was one. It would allow the site builder to go through the sitemap and create all pages beforehand, set up a URL path for each one, maybe choose if the page is displayed in the main menu etc.

If a site builder is able to choose which page she/he wants to modify, the step 4 is much easier.

Item 2: Set up page layouts for each page

Because of HTML and CSS language, what a site builder is really interested of here is what the actual HTML structure of the page is going to be like. Also, she/he would like to have an easy way to define the grid layout of the page, preferably separately for different screen sizes.

Each of these sub steps is somewhat complex, but quite possible to solve in a nice way, so let's not get into too much details yet. Let's just assume we have a user interface that displays the layout of a certain page and allows user to do the before mentioned sub steps.

Items 3-4

These are out of the scope of this case. The content type editing works reasonably well already in Drupal 7, and it's easy enough to create content in Drupal 7.

Item 5: Choose where the content items are displayed

If a site builder has accomplished the previous steps, she/he has some pages (with individual urls and layouts) and a bunch of content items. Now, next step would be to choose what should be displayed and where.

There is multiple ways to design this. One would be to display the same user interface as for item 2, but add a possibility to choose the actual content of the container. There could be a link labeled "choose content", which would display to a filterable "content pool", from which the user could choose the correct item to display.

And that's about it. If each of those steps would be optimized for usability, that would cover a big part of the time consuming work a site builder must do, plus make the whole process way more understandable than the current system.

Thanks for this task

yoroy's picture

Thanks for this task breakdown Mikko, very good and useful to have.

  1. Yep, we lack a Page library, the concept of Pages as we use the term here is missing in core (no, it's not the content listing :-)
  2. Is where you define your page templates, the 3, 5 or 20 templates you want to set up to create individual pages from
  3. and 4 are out of scope indeed
  4. This is the part of the system that would possibly be exposed to content editors as well (1-4 are mostly site-builder tasks and tools). It seems to make sense to model this after the UI in point 2, but like all of this, we should explore it.

I agree with your conclusion. If we make these steps doable and usable we'd make a giant leap forward. Thanks again, I think this would make for a good outline of what we want to work on while in Denver:

Clarification of Initial Stories

edward_or's picture

This is a very interesting (though you do need to read it all a good few times :) ).

One thing I am a little confused by were two of the initial user stories

I want a request to node/nid/history (with request type HTML) to be a list of teasers of the revisions of that node (nid).


I want to configure a request at foo/bar, request type JSON, to return the 3 most recent node titles, as JSON. Then I want to set up another request at foo/bar, request type Atom, that return the same 3 titles, but as ATOM/XML.

These both seem to be overlapping with something like basic views functionality. I would be interested in hearing more about this overlap (is there any, are there further examples, etc) as I had not considered this aspect of handling requests/responses previously.

overlay 2.0

kika's picture

Here's my conversation with Crell from Feb 2012, pre WSCCI-split days:


Could the proposed Symfony-backed Superblocks eliminate the need our
hacky iframe-based overlay? So the Superblocks could just generate
two set of blocks, regular "background" blocks and another set of
"admin" block(s) with different contexts (with different theming information) --
and these blocks could just be overlayed / rearranged using CSS.

Getting rid of the hacks around iframe (just look how the top tabs are
currently created!) could untie UX / MUX team hands and allow to bring admin
experience to a whole new level.


I don't know that WSCCI would help with the Javascript/iframe insanity that is a modal. That's HTML being HTML, and not something we can really fix server-side.

However, depending on what happens with layouts it may simplify the server-side. The iframed overlay version of a page would just be the same body but with a different "wrapper" layout. Basically, we get alternate page.tpl.phps in a more Panels Everywhere-style way than the hacky way we do now.

Thanks for the tip on Overlay. I hadn't really thought about it, but it's a valid use case.

I think effulgentsia brought

neclimdul's picture

I think effulgentsia brought this up at the summit. The iframes are hard to get rid of because of the admin theme and CSS rule collision, javascript, etc. As Crell said, we're likely only going to be able to try and make the process of returning it less painful which hopefully can end up with some net gains.

Note for the future

cosmicdreams's picture

I'm writing this with the full knowledge that this isn't a solution for right now. But in the future CSS collisions will not be an issue as long as we scope them. We'll be able to use this:

Software Engineer @ The Nerdery

cpelham's picture

I think we also need to be able to easily access a list (say via a link from each node, menu, custom block, views display, entity, user, etc) of all the pages where instances of said node, menu, user, entity, etc. appear (a list of all the contexts with which it is involved). Currently there is no one place where we can look to see where we have placed a particular piece of content. For instance, a views display does not know on which pages or in which blocks it will appear (except for the views page view that has its own url). and a node does not "know" all the places it is being asked to appear.

Thus, we may sometimes change how we style a particular piece of content (or output its fields) and inadvertently change how it looks on a different page/place on which it appears that we have forgotten about and did not want to change. So making changes to a large site of thousands of pages can be scary.

Does this make sense?

I guess this would involve adding a table to every entity that included a list all URLs on which the entity appears, or at least all the rules that determine where that entity might appear (some will of course only appear on certain pages if certain conditions are met...), which would probably create ridiculous overhead.

But is there anything that can be done in this direction that would not create tremendous overhead but would still improve the situation?

Maybe the better solution is simply to improve the site search functionality in core? or to let site builders know more clearly and up front that if they truly want an effective way to ascertain where particular content appears on their site, then they will need to implement one of the more powerful contrib search functionalities (which requires hosting resources that not every server environment can provide)?

Christopher Pelham
CRS (Center for Remembering & Sharing)

CRS (Center for Remembering & Sharing) is an arts & healing center located just south of Union Square in Manhattan.

Interesting. Pretty sure this

yoroy's picture

Interesting. Pretty sure this need comes up at one point or another, especially when there are many 'assembled' pages in a site (with lots of components on them).

I'm reminded of this question & discussion:


kika's picture

Squarespace has a nifty layout manager as well:

User Advocate's picture

Just to follow up on my previous thoughts about the concept of IA Space, I've recently had a chance to document how I've used it for a project I did last year for a community of regional Science Fair organizers.

The goal of that project was to help the non-technical site owners get front-end web sites and be able to easily add their region specific content. Since the regions generally had the same requirements for site structure I used my IA Space module to drive a site 'factory' system that eliminated much of the tasks of site building with one click.

Even though there was no UI built to configure this 'factory' (you'll see it's done in code) I think the concept is similar enough to some of the key concepts here. I think it's worth considering for the light it can shed on defining web sites as IA Spaces which has a direct connection to the Page Manager concept as well as Drupal's menu router. I've described the connection in a set of articles and in a 5 minute video on my tuag site.

Also, I've just put up the PDF version of my UX review of Panels and Page Manager on the Myplanet blog at

If you're heading out to Drupalcon next week I hope you'll get a chance to check out some of this material. I'm looking forward to more brainstorming on all this.

Michael Keara
User Interface Systems Architect,
The User Advocate Group

Context by Content

sebas5384's picture

Every time we develop a website, always comes the case to have a block to a specific type of content, like for example a News Page(node), where would be a context with the reaction nid==n, and the reaction is block A in the region "content bottom".
So for that case of use I use a contrib module that I create and it seems obvuis to have that functionality, and the it cames really handy using the in-line editor of Contexts for blocks.

I hope this comment helps :P