Context UX – use cases

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.

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.

Summary
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. :)

Cheers,

Michael Keara
User Interface Systems Architect, Myplanet Digital

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!

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.

@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

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

Eclipse

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.

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

kika:

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.

Crell:

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.

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 http://myplanetdigital.com/ux-review-panels

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.