Drupal’s site building user experience currently consists of moving between a lot of different tools and interfaces. Within Drupal 8 we want to unify these experiences (blocks, menus, views, panels…) more.
The experience that we are focusing on, is that of creating the front-end of your website - where content, blocks, views, menus are placed on pages and how these can be configured.
The proposal outlined below is for Phase 3/4 of WSCCI which is still some months away - it should be clear that this is just a high-level idea, and all details still need to be discussed. Earlier discussion on this topic can be found at http://groups.drupal.org/node/137469 .
This post was written by me and yoroy, with feedback from a number of core contributors.
Problems
This brings us to a fundamental problem that new users and even existing users face when they use Drupal: they have to learn “what kind of thing” each part on the page is - is it a block? is it a menu in a block? or is it a element provided by a module?
From usability testing we understand that people do not see the difference between the different parts of the page. Everything is simply content displayed in a specific (customizable) way.
Instead, Drupal forces users to build an understanding of its own internal implementation model.
After using Drupal for a longer period, this initial problem often gets even worse by the lack of connection between the different tools. A classic example that trips up both beginners and more experienced people is that after creating a menu, you need to remember it is a block, leave the menu page and go to the block page to make the menu visible in the front-end.
Contributed models like Views, Panels, Page Manager and Spaces try to solve this experience by providing “builder” tools for creating pages and making new block-like components that can be placed and configured.
A lot of smaller contributed modules create one-off pages and/or blocks for their specific uses cases. The interactions used for these pages and blocks are very diverse: one creates a page automatically, the other requires you to do it using a content type.
Lets take a step back...
All the different site building tools provide ways to create a page and/or elements that live on a page. They do this in different ways, each with their pro’s and con’s. However the biggest problem here is the lack of integration or a unified approach. So, the over-arching problems are:
- Users need to learn multiple concepts (blocks, views, panels, menu’s)
- Users need to move between different tools (menu -> blocks, panels -> views)
- Users need to learn how to configure each individual component
One of the major problems of the current contrib space as well, is that due to the need to accomodate for more complex use cases, the simpler use cases become hard to achieve. Moving a component from the left sidebar to the right sidebar for example.
We can say, Drupal as a whole - has difficulty providing tools with good UX for building the presentation(front-end) of the site, but excels in the back-end that of building the content model(content types/fields, taxonomy). This problem is not exclusive to Drupal, it is a problem that most CMS’s face (are yet to face).
UX Strategy
Defining an over-arching strategy for this will help us make more effective decisions during design and build. Some high-level design principles that can be applied to any of the specific parts of the design:
- The page is the whole page and I can manipulate the things that are on it.
- My tools should live close to the object that I am editing.
- Core should provide an interface (should focus on unifying the interfaces, so that more complex contrib functionality can hook into it).
- Don’t over-promise in core. Early and clearly point out the edges of what core does and what is up to contrib to provide.
Basic approach
It is tempting to now start imagining the wonderfully smooth drag&drop page editor that we want to build for this. But most of our challenges actually exist a level before that. We should focus on establishing the main concepts of ‘pages’ and of ‘components’ first.
We see pages as; the whole page with all its components, and any page from , node/123 to node/* and content-type/*.
We see components as individual parts of content: blocks, nodes, menus, views, panes, forms to fields, site title and slogan are all components.
To establish these two core concepts, we propose to start with designing:
- A page library for browsing existing pages (front, node/*) and creating custom pages.
- A component library for browsing existing components (blocks, views, menus, etc) and creating new ones.
If we focus on making it easy to navigate pages and components, we will solve the majority of the workflow problems with creating and editing pages by adding and configuring components.
To demonstrate we think the model is :
Most of these decisions are made from insights in the previous discussions on this topic and our experience from observing users.
“But if a View just created a component, and put it into a library, and then over here where you're generating a page layout, you can add that view to your page as a component?
If everything worked this way, the perceived complexity would diminish. Instead, our complexity would be about finding and identifying the components you want to use on that particular page. But that's a fixable problem. We can write awesome search widgets and stuff.” - merlinofchaos
Let’s cover two of the main concepts:
Page library
Page library consists out of all the pages in the site, these are the system provided pages such as user/*, node/*, front to the custom pages that you make yourself, to pages provided by modules. The library lists all these pages categorised.
The page builder part allows you to create custom pages, for example to make landing pages. But also allows you to edit existing pages such as node/1 or node/*. Within this page builder you can move in components, and configure the page itself (e.g context, layout, categorisation).
For every page you can configure the context, by default this consists mainly out of Drupal context’s with extendability for contrib to add contexts.
To recap, the page library is an environment to:
- Listing of individual pages
- Creating or editing a single page
- Browsing page relationships (master, child relationship such as node/1 and node/%)
The greatest challenge in designing the page library and it’s builder, is finding the right page (especially, in the case of page relationships)...
Component library
The component library allows you to browse, search, filter to the right component. This library houses any component that exists, from core exposed components such as blocks, menu’s, fields, site-slogan to contributed provided as views, panels, poll etc.
The component library is similar to the idea of blocks, the difference being that components concept is about turning any “part” of the page into a component and becoming the central place to find and configure parts that exist on the page.
An additional advantage to this model is that we can unify the configuration process of components, meaning that regardless of which specific type of component you add to the page you can make use of more standardized workflow for this.
Again, lets recap what the component library environment is :
- Listing of individual components
- Creating or editing a single component
- Locating and placing components on pages
The context for each component is at first determined from the page level, but can be edited individually per component. For example changing the display of a component when users are on a mobile phone.
Scenarios
To make more sense of this, consider these two site builder scenario’s :
Scenario 1
“I want to change the look of my About us page by moving the contact information content from the left side to the right side of the page.“
Jim goes and navigates to the About us page on his website, from this page he notices the “Edit page” link. Once he is on the Edit page mode he see’s all the different content (components) on the page, by hovering over the contact information he see’s he can move it and goes on and moves it from the left side to the right side of the page - after clicking save he is taken back to his page and see’s the change.
Navigate from the front-end -> Edit a page -> Edit a component
Scenario 2
I want to change the taxonomy listing of my sports vocabulary (taxonomy/3). I want to add a view that lists sport events in the sidebar. Because of that I also want to switch from a two column to a three column layout.
Paula navigates to Structure > Pages and boils it down from taxonomy pages, to the specific taxonomy vocabulary page that she wants to edit. On this edit page she clicks to add a new component in the sidebar, she gets to the component selection page and can browse existing ones or choose to make a new one. Once she chooses to create a new one, she can choose which type of component she wants to make and selects view listing from the list. After this she is presented the views ui, she goes to create her view - hits save and the component is shown within the page edit mode. She goes and edits the page, to change the configuration of thelayout from two column to a three column (she could have done this before creating a component), and moves the components to the right places.
Alternatively Paula could do this by navigating to Structure > Pages > Components. Goes to create a new component, creates the view and in the last step is presented with the ability to place a component on a page - to which she is presented with the earlier mentioned workflow.
Navigate through page library -> Edit a page -> Edit a component
Navigate by component library -> Choose a component -> Choose page -> Edit component
Context configuration
The configuration for contexts can happen on two levels, on the page level and on the component level. In case of page level context configuration you can go from the “smart default” of using the path or choose a different context you wish to apply. In the case of other contexts, you are presented with a browser for all the different contexts available: the core defaults and/or the ones added through contributed modules.
When it comes to component level context configuration, there is context supplied by the page but also configuration for the configuration itself.
The sketches of Itangalo illustrate nicely what this browsing could mean : http://groups.drupal.org/node/137469#comment-485784
The primary question here being, is this concept correct and what contexts are supplied?
Questions
-
Concept
- Are the concepts as outlined clear?
- Is this concept something that could create a “delightfull experience” for new and existing users?
- Could this concept capture all the pages and components that will be created in contrib?
- Can all types of pages be captured in this one system. If not, where do you see it break?
- Can, and if so, how will we handle hierarchical relationships (e.g how node/* is the parent template for node/23)?
- How do we solve the complexity that hierarchical relationships bring? (e.g. inherit from who $this type, or inherit for this language, inherit from the parent path, inherit from user preferences, etc).
- Can we capture the full complexity that contexts bring to these page and component levels?
Page
Context
| Attachment | Size |
|---|---|
| pagescomponents-small.jpg | 20.72 KB |
| pagescomponents.jpg | 85.03 KB |
| page-library-small.jpg | 26.47 KB |
| page-library.jpg | 100.21 KB |
| componentlibrary-small.jpg | 33.23 KB |
| componentlibrary.jpg | 84.4 KB |
Comments
Nice summary!
Great work, guys! This lays out the problem space really well.
Regarding the questions at the end:
Where I can see this breaking is the idea of "default" layouts. Eg, "my site is just a blog, I don't want to have to think about multiple layouts, I just always want my latest comments over on the left". Making it so easy to relayout any given page makes properly grouping pages trickier; If I click "edit this page" on node/5, then am I editing the layout on node/%, node/%article, or node/5? Any of those is possible. We may also want to be able to lock down layout, so that a content editor can edit the node body but not mess with the layout.
I am a little concerned about the impact of a layout-per-node on scalability. If the layout is wrapped up in the response controller configuration, that puts it as part of the router. If you start customizing a lot of nodes, that could make the router table really big. I don't know how nicely that's going to work, or if we'd have to add stages to the routing logic to account for it.
How do we manage the UI for "meta components"? By that I mean if you have 3 layouts that use the same blocks in the right sidebar and the same blocks in the footer but differ only by what appears in the top left of the left rail, how do you manage the footer and right side areas uniformly across the entire site but allow customization of just that one other area? The Panels answer to this right now is Minipanels, which is good for some things but the UI for it is nasty as it's split across different sections of the Structure area. I don't know what the solution is here. It won't always be hierarchical, either.
Recall that every component/SuperBlock has its own existence, and has an instantiated existence when combined with configuration and context overrides. So that's an extra level of complexity. (Eg, there is the "show a node here" block in code, and then there is the configuration of it that says "show it in teaser mode", "show it in full mode", etc.) I don't know how we handle that nicely. Would that map to the "create" logic above, with Views as the demonstration?
For context, that's still a fuzzy question, I think. The original intent was that context was slim, and was "the http request and things that descend from it". However, Panels/Ctools uses context is a much more configuration-driven way. And that approach is certainly quite useful. I'm not yet clear on how those two interact, or if we just throw it up in the air and say "well, overrides are flexible, so go to town!" One note there is that a given SuperBlock/component would have access to all context information implicitly, although for caching purposes it will need to declare in code somehow which ones it cares about. There's a lot here we still haven't figured out.
Lots of good stuff to think about!
Per node configurations
I'd also worry about per node configurations. Not just from a performance standpoint, but from a site management standpoint for larger sites. If you have more than 10,000 (100,000?) article type nodes with different layouts, how easy would it be to enact larger changes site-wide?
Or is that use case irrelevant because people running those types of sites would steer clear of this type of customization and we're more focused on people trying to use each page more like a blank canvas versus a a more structured architecture?
per-node
Currently we allow per-path page templates and per-node node templates (and all kinds of other stuff that's potentially infinite). At least part of this could presumably go away in favour of this?
Allowing for per-item overrides is definitely going to be tricky. If we wanted to do it in a way that scales, then we'd need to be able to get the layout after the router has fired - in terms of the menu system as it currently stands it would have to be determined after loading the menu object.
To me it feels like a router item could specify whether it allows per-item overrides or not, and if it does, then allow some extra logic to run (in a similar phase to menu_load_objects()). That could then scale as well as anything else per-item scales - the main issue being how much runtime performance cost (and complexity) it would add to allow the page layout to be determined that late - and once you allow that override, you're going to get the performance hit (if there is one) for all 10 million items even if you only override one.
It seems solvable to me, but is something we will need to think about earlier rather than later.
Scenario 1: Default vs Override
First: thanks for this extremely detailed and wonderful overview. I like this level of systematic thinking.
I have some feedback with respect to site builder Scenario 1. I come from a heavy panels/views use background, so hopefully that helps provide context to this feedback.
So Jim click's 'edit this page'. Edit what? The actual copy? The components? The layout? There has to be an easy way to toggle between these different aspects.
Overrides/Templates/Unique. So Jim moves the contact form from the right to the left on the about page. Does that now affect every page using this same template (like blocks)? OR, does this provide an override against the default template (like views). OR, does each page essentially become a unique layout in and of itself (like a new panel). If it's a template, Jim may be surprised to find that the block is now on the left on all pages. If it's an override, this allows all other uses of the default layout to remain the same, but requires some way to track that this is an override. If everything is totally unique, then changing themes and layouts site wide becomes a tedious process.
Really this boils down to front end UX simplicity and tracking all the larger repercussions in the back end. If we consider each page unique, it's super simple but becomes bloated and difficult for site wide changes. If each page is a template, we're back to basic blocks. If we use overrides, that is a great compromise, as long as the number of overrides are easy to manage and not confuse the user.
Anyway, just my 2 cents. I'm hoping to hear a lot of additional feedback on this thread. Perhaps someone else has an elegant solution to this and the other questions you left us with.
Page editor always go along with page manager.
I was stumbled upon these app creator software i.e. App Inventor, Appmakr which I think this same concept can cover a lot of use case, even things that are quite complex. And I think can apply to web page design and website architecture too.
Since I've background on publishing and 3d modeling, I think there're a few concept that share between 2d&3d design management and website page management. There're always 2 kind of stuff we have to deal with, object and abstract stuff, and both 2d (InDesign) and 3d modeling (3ds Max, Maya and etc.) do the same thing. They use two kinds of structure management like Outliner and Node editor to manage simplest brochure to million dollars hollywood movies, which I think the same concept could apply to theming and site architecture which always be "object" or "abstract" thing. And in 3d industry, artist work with programmer like how website built nowaday.
Node editor can handle more complex architecture, while outliner can manage pages in groups, sub-groups and individual page easier. And If we do use page templates and also break it down to smaller parts header, body, sidebar, footer and etc. templates, one who planned well will be able to do a lot.
So this is why I think we need structure management sidebar (or equivalent) along page editor too. This sidebar will do the things that can not do visually like context,rules and relationships. So we can do as much on the front-end as possible.
The more thing can accomplished on the front end, the more Drupal can empowered user and everyone who involved the project. And Drupal will grow even more.
Of course, we may not be able to do all the stuff in D8. But for sure, we are going to have strong ground and good roadmap.
John
Great writeup and very much
Great writeup and very much in line with my own wishful thinking about what I would like to see in Drupal 8.
Answers:
1 - Yes, easy to understand
2 - Definitely
3-7 - I know to little about the architecture, API's etc in Drupal to answer these.
One thing that I believe is not covered in the text is how to manage especially the custom built components. Since they are reusable they can be used on more than one place. The system will need to be able to tell where on the site they are used.
Then what happens when a component is modified? Such as fields, layout, settings etc is added, changed or removed. How will this be managed so that it wont break anything on the pages it is used on?
Maybe one option could be to be able to set that configure that when modifications require changes where it is used, the old version will be used until someone manually updated the display to the new version. If no such update is required, the display will automatically use the new version.
If these components also will be context aware, similar to View panes, then that also will add more complexity that needs to me managed. It will be important that automatic changes can't be made if it risk breaking these context links.
I believe these are important issues that needs to be managed invisible for those that are going to use these components to design and change pages. They are important for the same reason given in the beginning about how different a Drupal person and normal person see the information on the pages.
--
/thomas
T: @tsvenson | S: tsvenson.com
block visibility
One thing with overrides vs. templates etc. is conditional blocks.
Say I have a block that shows for users depending their age, whether they committed a patch in the last month or something else that's arbitrary. Or for nodes that only shows if the node is tagged with a particular term.
Technically the block is going to be shown on every page for whatever subset of pages it's configured for, but it won't actually appear unless the conditions are met.
Presumably if there is a separate edit interface from the actual page, then those blocks could just be shown there as editable. So that may not be a problem, but better mentioned than not.
several contexts
On the context consideration, I'm not sure this plan maps well to having a couple possible contexts and their intersections. Say you have a context for "logged in user" and one for "language". Now language itself can be any number of contexts, "German", "Swedish", etc. So what if I want to put a block for logged in users on the German pages? What if I want it to appear across all page types but only for the cross of these two contexts: "logged in" and "German"? I think the "editing UI will be replicated for each context" bit falls down on that it needs to be replicated for each possible combination of any number of contexts as well then. What if I have 3 languages, user login, geolocation, etc. as contexts?
Reducing complications
Let's think of a bit of "standardisation" in order to make things simpler and possibly less power-consuming.
For example: why we have panes and blocks as separate things? If they differ only a little, let's use only blocks, also within panels, and eliminate panes. I don't know about mini panels in this respect as I tried to use them without success (extremely unclear setting up).
Another example: You are right that multitude of context dimensions can make problems, like various languages, user status etc. Why not think about some standardization - blocks that have choice "current user" and "logged in user" as a standard?
Going further with this approach let's consider what should be a standard "equipment" (or context awareness) of the block? What to choose? For me, user status, content type viewed and the list of pages (as actually is) would be enough. Next question is what STANDARD mechanism should be recommended to extend this. Plugins? A kind of "advanced settings"?
The same approach could be applicable to the Views. Many people complained that Views are taking "all database". In the Plone project they have so called "brains" (AFAIR). Standard query takes from database only a few data, i. e. ID, Title of the node, the description, date and author and not more, AFAIR. If anybody needs more, she or he can call simple function (lets say get(ID)) and using this function take from database what needed. However, I remember that using this technique I made a crash, so the idea should be thought carefully.
That is the plan
A major portion of the WSCCI initiative is exactly that sort of standardization. For background, see: http://groups.drupal.org/wscci/definitions
In essence, we first build a unified context system, then a unified plugin system, then improve the routing system using those two to be in essence "services in core", and then use all three of those to implement "panels in core" to replace the current page layout/workflow. So what we now call blocks go away, and are replaced by a plugin-built SuperBlock that is very akin to Panes in Panels.
Every SuperBlock (which would probably just get called Block when we're done) would take in a context object (which has all kinds of useful information, plus overrides) and potentially admin-defined configuration. Anything that is placeable (what the original post calls a component) would be one of these SuperBlocks, period.
The question here is what the UI process should be for configuring those layouts and fancy-pants Blocks. The current Panels UI is, I think everyone agrees, insufficient. The question is, what's the better solution?
Compexity and variability
Oh, yes, I have read these definitions some weeks ago when I was too young in Drupal to understand the breakthrough.
I perceive this plan as very needed and inevitable step to reduce apparent complexity through concentrating it in as few objects as possible. Esp. Your Butler object I see as analogy to the logistic terminal in which the trucks, palettes etc. are unpacked and then the commodity is composed to the complete packages dispatched to the receivers. Such move is a great measure to reduce apparent number of "transactions" (relocations of the goods and/or other values). Every big artificial open system needs such restructuring on the way of its development.
This plan regards reducing complexity, i. e. the internal apparent interconnections and interdependencies (incl. communication). My above note regards the other aspect of restructuring - reduction of complications or variability. Complications are everywhere where it is too much various things: to many content types, too many entity types, to many principles and exceptions, too many ways of action, too many patterns etc. Also every artificial open system needs to fight against such internal "bureaucracy" from time to time, as the complications always tend to deposit and grow.
Sorry for such long explanation, but I think it could be helpful if I reveal in details the point of view of Industrial Engineering. My main idea here is only to suggest that reducing variability should be done prior reducing complexity, in order to avoid unnecessary effort to automate the mess.
Let me attempt a solution at
Let me attempt a solution at your problem, while raising some more questions.
We need to map a context to a layout in an efficient way. So we could have a two column table with regular expressions for each context(a sequence actually, one for each data field) as first column and Layout info as the second column. Given a context like [path=/home,language=german,user_role=contributer], we match it with each of the reg exp in the first column in the table, and gather a sequence of layout infos. So since we are matching the context with reg exps, we dont need to edit ui for each many different context.
There are some questions about this system:
How do you sensibly combine different layout infos to create a single layout?
If there is a way for making this sequence into a hierarchical tree, we can say that the layout info in the children take precedence over the parent when in conflict. But can we implement such a hierarchical system, without reducing the expressiveness of the regular expression?
Will the table be large and thereby make this system inefficient?
Can we implement a ui which conveys this abstract model to the user in a clear way?
Thanks for putthing this
Thanks for putting this together.
May I suggest that we use the dashboard module as a playground for this? It is already in core, and it sucks. I think its use case is a subset of page building so it is a good ramp up to a full page builder.
Great suggestion
I second that suggestion and would like to add making the dashboard available for any user to be able to create their own personal home page, much like the dashboard on d.o. That way, there is no need to add a contributed module for something that already is almost there.
That would create an isolated use case where things such as context awareness, especially on the users own dashboard, can be limited.
--
/thomas
T: @tsvenson | S: tsvenson.com
Start as contrib for Drupal 7
If this would start as improving the admin dashboard, as well as make it available for any user, then it might be a good idea to make it a contrib module for Drupal 7 that improves the bundled dashboard.
--
/thomas
T: @tsvenson | S: tsvenson.com
What to see, what to drag? Let's try fundamentals
First handful of my thoughts.
To avoid chaos in discussion I would suggest to distinguish between various perspectives of our focus, e. g. if particular standpoint's focus is user-centric, tools-centric, content-centric etc. Secondly, I think it is valuable (albeit sometimes irritating :-)) to always keep fundamentals in mind.
My experience is mainly user-centric, as I treat my sites as more or less interconnected collection of services for the End User. So I see 2 "strata" of the issues of architecture:
- those related to end-user;
- those related to admin/site builder.
(There are also the aspects of business, such as SEO.)
This difference is clearly seen in the first illustration above. However, it follows from my observations of new end-users of any website that more fundamental question is what they don't see. The observation confirms an old findings that the content and the interactivity are two main drivers of WWW.
So, in CMS like Drupal, users usually see content, and don't see main menu, interactivity tools as "print", "comment", "flag", "add to bookmarks" etc. If the content is invaluable they go.
On the other hand, in social websites they usually see interactivity tools because they are specially exposed. In FB the "I like it" link is attached to every small piece of "user-generated content". No matter that often it is a garbage rather than content, because it is interactivity that drives FB.
In most of Drupal themes, interactivity tools are almost invisible! Maybe we should consider to radically improve exposure of interactive tools, including some new ones. It seems not a big task at the first glance, however it should include not only fresh concepts but also clearing some minor drawbacks like limited functioning of relative links to "create" and "edit" entities (working now only from root site level when used from panels etc.).
Bigger problem, in the admin-focused "stratum", is mentioned above - confusing chaos and complications of the WWW page elements (menu block, blocks, panels, panes etc.), and complexity of them in the back end. Most new site builders can't even understand what are the nodequeues, and the concept of queue. It is practically impossible to remember what are the sources of particular blocks or panes.
So, if it is impossible to remember, please let's think about the solutions eliminating the need of remembering. One possible solution I know is that of guys from Ning. Every configurable block in the main page has the form exposed, and this form itself indicates the data source of the block. One form is to fetch RSS, another block is to choose if we want display random videos or queued ones (they say "featured") and how many of them should be displayed, another block is simple HTML text. Small simple exposed forms are really great!
As to the presentation issues seen from content-centric perspective, I would like to suggest first to distinguish static page, one separate entity, and composed artifact such as panel. It seems to me that context dependence of each of these three is different.
Some thoughts
(Having now actually read the definitions associated with the WSCCI, I wanna take back my previous comment and hope to return with something that fits better into the current discussion. Pardon any confusion.)
A stab at two of the questions
Here's some thoughts of two of the questions at the very end of this inspiring post:
(4) Can all types of pages be captured in this one system. If not, where do you see it break?
(5) Can, and if so, how will we handle hierarchical relationships (e.g how node/* is the parent template for node/23)?
Can all page types be capture?
I think there are some problems – I consider pages as special cases of what this configuration UI should be able to capture. My main concern is probably the panel-like layout, that fits well with HTML pages but won't make sense if you're configuring the content if a JSON response.
This could probably be handled by having layouts being a wrapper component, that may contain multiple components, but that will cause some other problems. When viewing the list of HTML responses, you want direct links to change both the layout, and the content – which means edit links for both componens and child components. The same kind of links wouldn't make sense in a list of JSON responses.
Of course, you could build in pages as a special case and treat it differently, but that would go against the idea of building a unified interface (and also having Drupal agnistic towards different types of requests).
I don't have any good ideas on how to solve this. :-/
How can we handle hierarchical relationships for pages?
This, I think, is quite doable. Suggestion:
Again, pages is just a special case – this would work for other response types. (And, I guess, also when configuring components that don't relate to individual pages.)
One possible problem is ambiguous hierarchies. If you have "node/* and acting user is logged in", and "node/23", then a new page "node/23 and acting user is logged in" could be the child of two different parents.
I don't know how this should be managed.EDIT: In these cases, the special page should be placed as a child to the first matching parent – to assure that it won't be skipped in the selection process.Default page and global components
With regards to hierarchies and overrides - one assume there must be a global default page. If stuff like Site name, Logo etc are to be components we'll want to do that once in a default page and never again - unless we really want/need to.
So, how might this Global default page work - as a wrapper to all other pages, or as an actual page at the top of the tree which all other pages will override, apart from their global components.
As a wrapper - perhaps all other pages don't have access to certain "global regions" such as the header and footer. This seems weak and inflexible.
If its an actual page - then perhaps anything placed in that page is automatically global, unless it is removed in a child page OR its given a scope in its settings (I am not clear on what context type settings might be available for components or if all context is inherited from the page).
Good point
This is a good point. So far I have been thinking about the global default page as a wrapper, similar to how Panels Everywhere handles "site template". But with that model, the selection for different pages is moved one step down in the hierarchy:
HTML response+ Global default page
+ Default header
+ Default main content <-- This is our "pages"
+ Page for "node/NID"
+ Page for "user/UID"
+ …
+ Default sidebar first
+ Special sidebar for "user/*" <-- But selections also happens elsewhere
+ …
+ (Overrides of the global default page)
(Other response types)
This leads to two interesting problems:
HTML response > Global default page > Main content, but some site will require in-between steps, and response types like JSON probably won't have the "Global default page" step.I hope what I'm writing makes sense.
EDIT: Damn, I'm mixing two different things in the tree above – a component structure tree, representing regions, and a component selection tree, representing selection of what content to display. That there are two different tree will probably have consequences for how the UI could work.
Minimum
If flexibility is needed, minimum should be chosen. Minimum is the identifier - Site name or even a domain.
Then, in hierarchy, we have regions, and perhaps some regions with some components as a block with Logo inside could be a "default page" that is default but changed if necessary.
Or, maybe we should talk about default region or default block instead of default page.
Basic administration of composite pages
Assumption: Drag and drop functionality is obvious (and widely known) framework solution.
"Composite pages" I mean generally the pages that include regions, no matter if given by the theme or by the panels etc. For example in my recent site I have composite home page, group pages, meeting pages (meetings being groups), user profile pages and user's "private" panels.
The following sketches present Administration UI for menu creation and composite page creation.
Notes and remarks to the sketches:
1. Basic unification of the layout: the result is always on the right side, the "confirm" button always the same and emphasized etc.
2. Special attention should be paid to the second image, section "Configure XXX". There is a form exposing what View should be applied in particular case.
A collection of Views pulling user-created content could/should be unified. For example, in addition to almost every Nodequeue I added standard set of Views, and have: queued View, sorted View (without context filter), and User's View (should be filtered by node's Author = UID but recent Views has some problem, so I use the node's Owner = UID).
The remaining configuration should be SPLIT between inline exposed form (to be shown in the next post) and Advanced configuration (usually Views). I don't discuss here the Block configuration (in which pages it has to be displayed etc.) - only basic interface.
End-user should have some administration permissions as to his own profile page and the other personal panels. For example she or he should be able to choose if "all recent comments" or "my comments" should be displayed. This issue I shall discuss in the next post.
Inline editing
As I said in my first post, exposed forms for inline editing composite pages should reduce User's confusion and improve her or his experience.
Below is the exemplary solution. It is "extreme" as for actual stage of our discussion, although we could thing long time perspective ahead.
- Can we propose and fix any standard set of Views for particular content objects? (i. e. general, queued, user's view etc.)
- Which form elements can and should be exposed both in Basic Administration (above post) and Inline Editing, and which ones should be hidden -> left to the Advanced Configuration? For various use cases, and regarding permissions, roles, security, etc., and usability above all!
- NOTE: In this stage of discussion try to refrain detailed technological issues. Let's ONLY say generally that the content of the block is pulled/selected from database. It is important because in some future stage we HAVE TO discuss reducing variability of the pulling/selecting mechanisms, as well as dismantling complexity of layout/regions and context-dependent content configuration.
Page decorators + parameterized components
The realistic scenario is that on a typical page we will have a mix of component configurations.
* Some components are configured to show up on one specific page only.
* Others might show up for every node of this content type.
* Some components might be configured to show up within a specific organic group (configured by the admin of this group)
* Others might show up throughout the theme (not necessarily throughout the site).
Some of this configuration is from a drag-drop interface, other is just hardcoded.
And then for some pages we have a different layout, and the configuration becomes useless.
So, we need / want.
- Any configuration UI needs to clearly say what pages are affected.
- We need a way to merge / stack configurations on top of each other.
- Priority / order of configurations needs to be clear.
- A way to add custom wildcard-based configurations.
- Storage: Per-node configuration has to be stored as a node field, whereas others are stored in a custom table.
- We need a UI to pick layouts (or switch theme) based on specific conditions.
If we follow these ideas, then I'd say we call each step a "page decorator", instead of a "configuration" (my use of that term was quite desperate anyway). We start with the page callback, then run it through applicable decorators one by one, until we have all the blocks and components filled into their slots.
Another thing is the components themselves.
There are different types of these:
- pieces of content that exist outside of the page and can be reused.
- one-off ad-hoc components, that only exist on this specific page / configuration.
- parameterized components.
Or, do we really need all these three?
Nope.
We can reduce it to one: "parameterized component".
There can be multiple types of "parameterized component":
- a "node component" can be parameterized with a node id and build mode.
- a "block component" can be parameterized with a block id and a custom title (if we keep the term "block")
- a "view component" ... you get it.
- a "menu component" is parameterized with a menu name and some additional params as we know them from menu_block module.
- a "text component" is parameterized with a piece of text. Unlike the others, this component does not depend on any existing entity outside the configuration (decorator) it was created for.
Btw, in some other CMSes this what we call "fancy panels stuff" is the most basic native feature.
One example is Contao. (I did not work much with it, but this is what I remember)
Related implementation discussion
So, as a related note, the implementation logic we're currently looking at (although it is by no means set in stone) is here: http://groups.drupal.org/node/148149
While we should try to separate the UI discussion from the implementation discussion as much as possible, they cannot be completely separated. Issues like performance concerns will impact what we're able to do at all, which will impact the UI concepts we're able to build.
Also, some of donquixote's comments above discuss still having a page callback, and then wrapping stuff around it. That is the current model in Drupal 7, but the goal for Phase 4 of WSCCI is to reverse that; We render a series of components/blocks/content panes (they all fold into the same thing) essentially in parallel, conceptually, and then merge them together in a layout. That means that there is no "page callback" per se, at least not how Core understands it now.
That said, that does still leave open the DX question of a module that just wants to stick a form at a URL. I don't think we want to make a completely new layout or response-controller-record for each random page a module developer wants to put somewhere.
... or do we, since that is, actually, what we do now? I am not sure.
Keep it coming, folks. This is a great thread. :-)
We render a series of
One quite important design pattern I know of is the "Center stage".
http://www.welie.com/patterns/showPattern.php?patternID=center-stage
A lot of pages we see in websites follow this pattern: One central piece of content, and that is specific for this one page, surrounded by peripheral stuff, that is often the same on different pages.
This is why Drupal up to D7 has page callback + blocks.
We now want the possibility to break out of this model, to gain the same flexibility as in other CMSes where it is normal to arrange arbitrary stuff on a page.
We need to make it easy (as easy as it used to be) to make single-purpose page callbacks. Module developers should be able to map something to a url, without the user having to click around and configure.
But we also want that this same content can be freely arranged on any page.
So, we need to separate the page callback from the function that produces the html / form / content / etc.
Instead of a page callback, we would have a "component callback" that receives some parameters and returns the rendered html or nested render array. Then, we need a mechanism to bind a url to a component callback. Maybe a "page callback" called "single_component_page". The user, or another module, can override this and arrange arbitrary components on the page on that path.
Short remark and request
Remark: Although patterns are not the same as architecture, the "Center stage" of the page has architectural reference to the center slot (or block(?)/wrapper(?)). We can plug the article, forum, RSS feed, panel, products' catalog, calendar etc. in this slot. From that point of view, the apparent variability of patterns is reduced. Probably and the cost that we suddenly can see clutter in how they communicate.
I feel that when talking about particular kind of "skeleton" (in this case the stack of slots is a "type" of skeleton), it is inevitable to consider how things sitting inside them communicate. Or - more generally - how they request, receive and send data (descriptive mode) and program (imperative mode). There are various options of the architecture of "skeleton", and each of them extort a kind of communicative behavior, and each of them has advantages and drawbacks.
So, this may be very important question, as related to performance etc. But I am not developer, and don't understand some crucial notions. Therefore...
Request: Please explain me briefly what is "page callback" (Wikipedia is full of callbacks...).
Context
In the current plan, the idea is that every Block/Component/Rendered Object receives information into it as Context, plus admin-defined Configuration. If that block has sub-blocks, it will pass its context object on to child blocks. If it is configured to do so, it may override any part of that context, eg, to make it think we're viewing a different node.
However, a block may not, and if we code it properly simply cannot, affect the context of any other block that is not its child. That is critical in allowing one part of the page to be completely independent of another part of the page. If we can do that, then we can handle those pieces separately. For instance, they could be rendered in parallel in separate PHP processes, cached separately, returned to the browser separately for ESI caching or AHAH, and other such fun things. That's the basic "skeleton".
While that has conceptually been shown to be a viable approach architecturally (Panels uses more or less that model now), designing a UI to configure that sort of setup in its myriad possible combinations is quite hard. That's the goal of this and other threads.
Page callbacks are a current Drupal concept. Every page that is displayed is the result of a single function's output that generates the main body of the page. The menu/router system takes an incoming request and calls the one "page" function that is configured for it, takes its output, and then wraps blocks around it. (That's something of an over-simplification, but it's the basic idea.) That works fine for simple use cases, (such as this very page), and is conceptually simple, but also very limited for more complex use cases. It also presumes a single global configuration for the "stuff to wrap around it", which is increasingly not the case in practice.
Of course, we run the risk of the more complex model (above) making that simpler use case prohibitively complex to implement. That's a problem we need to avoid. How to do that is also a goal for this and similar threads. :-) We're not sure yet how that can/will be done.
Affecting only child blocks
Question concerning a blocks ability to affect only child blocks: If (derived) context data is produced by a block, should that only be accessible to its child blocks?
(I would say yes, for a few reasons, but that somewhat contradicts the idea of having one central butler that provides the context data.)
What's the answer according to the current plans? I think it will influence the UI, since the UI should be able to handle context data as well.
Edit: While I'm at it – do the current plans say anything about context data being added explicitly, as in Page manager, or are they declared and loaded at the same time as with D7 tokens? ("node:author:field_presentation_reference:title")
Basic UX?
Thanks. There are a lot of broad and not always clear questions, indeed.
I'm not sure if only the page should be the basic wrapper of all other things. Not a page, but page +user +time + (?) contains all the context information. So, looking for simplification (complexity reduction) I think about a possibility to distinguish some set of context data as a "Basic context" to be processed in unified (standard) way, and the remaining context data would modify (override?) or complement this basic set.
In industrial Engineering, and effective way to simplify and clear the issues of OPERATION (stuff processing) is to refine a complete of 5W1H questions and answers, step by step. As this complete doesn't involve the stuff itself (as it is given, which is NOT our case), we should add it to the complete.
Of course I'm not sure if this technique would help us to simplify the issue. Below is the first step in such a thinking:
Operation (stuff processing) - Cut the Basic CX or not?
=======================================================
==========================================================================
Question Examples Relevancy of Q Other questions Basic CX?
and notes
==========================================================================
who current U, Yes Yes
role
--------------------------------------------------------------------------
when event, Yes Yes
RSS
--------------------------------------------------------------------------
where content, probably not Place or action?
admin/
config.
--------------------------------------------------------------------------
what (object) article, probably not
form,
flag link,
......
--------------------------------------------------------------------------
what (user do) view, probably yes
create,
flag,
poll,
....
--------------------------------------------------------------------------
why Is the U'goal
relevant?
--------------------------------------------------------------------------
how (deploys to
what U do)
==========================================================================
Above example suggests that and Object + User + Time should be a complete basic set of information that determine the looking and actions of other "things" like blocks.
Where to cut?
To precise: The question is where to "cut" all the context in order to divide it into Basic CX, and remaining CX usually called by various "configurations". Optimum cut would distribute processing power between these two. Moreover, Basic CX processing should be agnostic of context elements provided by contributed modules (?) and... what else?
If so, I think we should add Taxonomy to the Basic CX, so as it should check: an object type (content type and Entity type; what else?); current user and permissions; Date and Time; Taxonomy (tags etc.).
Next question: if this "cut" should also determine the basic processing of the Super Block?
Or all the idea of such cut is false?
Background
Please see the following links for some background. It sounds like you're just a bit behind the discussions that have already worked through some of these issues. :-)
http://www.garfieldtech.com/blog/web-services-initiative
http://groups.drupal.org/wscci/definitions
http://drupal.org/project/butler (where we're working on code now)
Super blocks
My intent is to discuss possible simplification of the Super Block. I know it is in Phase 4, but it's architecture and functioning determines so much of how other things should be arranged.
Simply, I think that having - say - 20 or 25 super blocks in the main page, together with all machinery behind, looks like technical nonsense: far too much. Of course, we can simplify UI replacing such things as variants with something simpler, however, such move doesn't reduce complexity nor variability.
Therefore I think about a block with some basic configuration as standard, with the option to switch advanced setup on. This advanced option would be also conceptually simple, as a socket (slot?) for extra plugins.
Same?
I don't think what you're saying is inconsistent with what is already being discussed. A simple block that doesn't offer more than one checkbox for configuration needn't be complex at all, but it can still use the same underlying mechanism as more complex blocks that legitimately need more.
Independend blocks?
I'm not sure. What about such service as "Related content" block? Should it be able to call ONLY a body or also the other block(s)?
Personally I am convinced that in far future IT should descend the tree, because the nature of the world is not a tree; it is more like a net. For this philosophical issue please see my article.
Above
Both the main content block and the related content block pull the "which content am I talking about" information (usually the primary nid on the page) from the context, which is passed into both of them. So they don't relate to each other directly, they both relate to the incoming context. That separation is what lets us keep them "linked" but still handle them separately when needed, as well as fake-out one or the other.
Grasp, route, process and respond
Obviously. However, when we perceive routing etc. as a process, it is not necessary to presume that a sequence "calling a page and THEN wrapping blocks around it" is the best or even good.
Below I draw a simplified block diagram of the general data processing governed by the system requirements and or conditions of START subprocesses, and by the routing process. It can be used as a general design framework.
(sorry, I see that some elements of the sketch disappeared [ah! awful technology :-)]. Please compare with the sketch below, and You can see what is missing).Here I assume that first of all we ask "What we grasp and in what a sequence?". The answer determines majority of the "response building" design.
For example the sequence could be building all the screen "layer by layer" or "layer over layer" "frame within a frame" (matrioshka :-)) etc. A layer or a frame are represented as the "subassemblies" in the sketch. This is the example of the alternatives to the "calling a page and THEN wrapping blocks around it" sequence. Probably such sequential process requires solving some persistence problems, but it is another story.
Probably a lot of sequences and other "process architectures" are possible. It follows from this remark that it is very unlikely that a unified routing (REST?) process is a good solution. Rather it would be pluggable or, at least, there should be possible to rearrange the sequences.
Red hexagons represent routing process in the sketch. Besides, I draw a START criteria because there are often ignored in software development, esp. when simplified or reduced to the notion of trigger (or event, which is prohibited in Industrial Engineering [IE] for serious reasons). However, there are many other cases, as for example the synchronization requirements, decisive points etc.
There are parallel processes it the sketch. BTW, I think that integration of routing process with such mechanisms as the Rules should be taken into account. Maybe some routing subprocesses could be delegated to the Rules?
Solving the puzzle such as above sketch is the first step of process development in IE. The 5W1H questions mentioned earlier (6W1H in our case) facilitate the task, as well as 4 general techniques of process architecture development: Eliminate, Combine, Rearrange and Simplify [the elements of the process until significant improvement is attained]. Further more detailed analysis is often applied, usually in the form of flowchart or the like. The example sketch is below.
I'm not familiar with the REST logic, but it seems to me, that it should be assumed, that some of "subassemblies" could serve as the REST response (not only the complete "pages").
Process and process control
BTW above is the proposal of explicit differentiation between process (data processing) and the control of the process - the subject of my long-lasting dispute with the advocates of BPML who tend to mix these two.
First thought derived from
First thought derived from the above:
"Whole page" (screen) as seen by the site admin as the hierarchy of alternate stiff and movable (weighted, queued, dragged) elements:
- HTML frame, header, footer, regions, panel's canvas, book cover - stiff
- blocks, panel regions - movable
- block content, panel panes - stiff
- ...?
Maybe it would be a sense to design general parallelism of the routing based on this? I mean stiff elements could be rendered in parallel with movable ones, and THEN glued together.
Overly complex?
I'm not sure I follow the "grasping" concept. Reversable rendering pipelines seem like far more complexity than we could manage, and the performance impact makes me cringe. We have to make decisions somewhere, although in general I agree that more pluggability == good in most cases.
However, what you're describing in this last comment is, actually, what we already have planned. Each block becomes independently (and therefore parallely) renderable, and an HTML page response is simply an amalgam of such blocks stitched together in a layout. (PHP itself is not multi-threaded, of course, but once we have such separable pieces we can experiment with all sorts of exciting things, from ESI to BigPipe.)
We're drifting well off topic for this thread at this point, though. However, it sounds like you're overall describing the already-existing architectural vision, so we're all on the same page. :-) Let's get back to trying to work out the UI we would need for phase 4.
To visualize the idea.
Thank you for your hard work.
I do use Drupal and Wordpress. And I've did some research about user friendly WYSIWYG theme editor on wp.
I found that Headway themes and Carrington Build are the finest in this aspect on wp. And I think our plan is comparable to the most user friendly commercial wordpress theme builder tool at the moment.
I have watched 1 2 3 video on headway and did tried Carrington demo (In "Pages/ Build tab). I think Drupal can do as good or better because of coding quality, scalabilty and we do it as community.
I'm not so experienced in Drupal ,but I will try my best to help.
Regards,
John
As to the UX side:As we are
As to the UX side:
As we are dreaming wild, it would probably be good to explore solutions that are already there inside Drupal.
Or maybe, as some people stated outside of Drupal.
The Carrington Build Demo video (watch the one at the bottom of the start page as well) looks very good. A mixture of Buzzr and Panels, isn't it?
From the times I visited it, I remember Buzzr tried to solve the problem of inserting content elements (blocks) everywhere in an adhoc style.
Also the In-Place-Editor of Panels goes a long way to intuitive editability of the page (if it would only work :P)
If Larry is to take the page rendering apart as completely as he threatens to, the limits should be more of what can be concepted, coded and solidified in a reasonable time.
From some discussions in the Drupal 7 UX phase I remember you simply could not edit some stuff in place because of the page not knowing where stuff comes from. If this is going to be solved, man, way to go :)
Thumbs up to AndrzejG for providing screenshots. More of that!
Life is a journey, not a destination
How about?
So, it's look like we can actually do a lot thing in Drupal already, if we actually think about what Pagebuild, Buzzr, Drupal gardens, Sweaver, merlinofchaos's panel, etc. can do. So, it's not beyond current Drupal capability (but with a lot customizations), but it need a lot of resources for sure.
I think if the group able to informed and connect companies, project developers for collaboration, it's a win-win situation. The group can understand our problem and turn them to action easier from people who have did and experienced these kind of works. Drupal community benefit as a whole, there're always things that holding back both community and business need. And the collaboration will benefit to all. At least, many people who work with these company already get involved here and can share more insight if the group collaboration with companies too. Maybe, Dries as a Drupal leader may have something to say about this ;)
And what I think is things don't need all things don't need to be get in D8, but we can take low hanging fruit and most important thing first. And if it doing good, people will adopted and help extend it. And we almost have roadmap for 1 or 2 versions of Drupal in this aspect.
FYI, Corwdfavourite also built their site using their tool. That's means the site it self is the demo of this carrington build can actually do a lot.
Anyway, I'm apologized if it sound unprofessional because of my english and not a programmer people.
Regards,
John
Step 4
This thread is discussing Phase 4 of the WSCCI project. Phases 1-3 have to come first. So yes, if Phase 4 takes until Drupal 9 that's not the end of the world, because we still have (we hope) the benefits of phases 1 and 2 (vastly cleaned up internal APIs) and phase 3 (web services baked into core at a root level). Those are all being designed with an eye toward the phase 4 goal, but it is going to take a while, and the collaboration of lots of parties, to get there. If we can get some of the teams from Buzzr or the other systems you mention in here and talking, that would be great.
Oh yes.+1 for
Oh yes.
+1 for midterm-thinking to Larry.
Even if Dries implicitly planned for a 3-year development cycle of D8 (his 18-months after plateau of productivity paradigm means just that I think) we should definitely not go beyond that.
Fields in core have enabled such tremendous improvements to Contrib and finally UX one can already see the duality of code and UX pay off. Do one thing - and do it right.
I still have Matt Mullenweg mocking us for wanting too much resounding in my ear. We better not complain and find Excuses why Wordpress is by Orders of Magnitude more successful than drupal. We better steal everything we can from them to follow in the footsteps. Including a Development Cycle not longer than Necessary and Courage to leave out things. In three years time the web will have changed so much we can not plan ahead for that anyway.
Life is a journey, not a destination
I agreed, I must be drunked.
Yes, it's no way to plan long term this day. I was drunked, and too wild imagination ;) And I really love 'steal' ... , I mean learning and inspirations.
Today I stumbled on new acquia site which based on Omega. This theme is into something, when using with Delta and Context, it's not a theme but a bunch of design tools which many design aspects can be done a lot with configuration. Worth checking out if you still haven't.
So, the most interesting part is:
The creator, himerus is very active and done a lot of mind blowing stuff. Maybe it something so actionable if the group informed him about what we are into.
(And ... just hope I'm not drunken this time)
Like Sitefinity
This all sounds a lot like Sitefinity, Telerik's CMS which is written in .NET. In that CMS:
The entire approach should remind us of a Drupal site + Panels + Panels everywhere + in place editing, on crack.
Software Engineer @ The Nerdery
A long overdue
A long overdue comment! We have been following all the comments and there clearly is still a lot of stuff that needs more consideration. There are a lot of challenges in solving something as complex as this. I feel like we are on the right track but we need to more clearly explain and discuss how we handle the "default" vs. "context-specific" use cases. After some more discussion, we will probably jump into the process of sketching this out to get a better idea of the UX challenges.
@Crell Thanks for your continious involvement in this thread.
@Gabor After talking on IRC I have outlined how I think we will handle multilingual configuration :
This same interaction would apply to components, you would be able to flip between different contexts and configure for a specific context as needed. @rickmanelius I believe the way that Views works with this makes most sense, but in many ways its a combination of the panels and views approach - with a more simplistic "default interaction".
To me the way to make this usable, is to have a clear interaction to navigate between the different contexts.
@Itangalo Can you explain more on the different "branches" of a page?
@Jeff Burnz Thanks for this great idea, that inspired us to reconcider how we handeld defaults. As explained above in 1) we do expect the need for a Global default page.
@AndrzejG I am sorry but your comments are either very technical or not really in scope of this discussion. Please for anyone commenting keep in mind, that we do not code - so please farme your answers with that in mind.
Let's say "Main panel" instead of "Page"
Let's say "Main panel" instead of "Page".
What we need first, as users, is the Main Panel editor. For placing and theming regions, we need something like himerus' Omega project.
For blocks ~ panes we need something like Merlin's panel editor.
Both above refactored, in order to make them more user-friendly, could be incorporated to the core, and REDUCE complications instead of building next layer of them.
So, we could have a library with one default Main Panel, and a variety of Panels (possibly those of Merlin but elevated higher in the site hierarchy).
Next we need a library of components. Again, something like content library for Merlin's panes, but containing more content categories, according to this proposal of Bojhan.
So, all this initiative could be thought as integration project, aimed not only to improve user experience but also reducing complexity and hopefully removing complications.
Some new sketches
Here are some renewed sketches, more or less replacing my previous ones. I have tried to focus on actual user interface, but some technical comments sneaked in anyway. Comments and criticisms welcome – this is (of course) just wild ideas. Here goes:
Editing pages and blocks
page 1 of the attached pdf
On each page, administrators have a contextual link menu for each block. The menu allow for editing the block settings, but also any of the wrappers/containers the block is placed in. (This should to the very least be the page template, but probably also region wrappers and possibly other mini panel-ish things.)
Block editing (general)
page 2 of the attached pdf
When editing a block, you get all the settings available for that block presented in a box. (See separate headings for more sketches on settings.) Just below the title of the block, the type of block is displayed. This could be view blocks, menus, or what have you.
In another box, you get the layout trail of the currently edited block – such as
page template -> right sidebar -> block X. If the same block is used on other places on the site, this is listed below. All layout trails are linked, to allow the administrator to jump to wrappers containing the block, or other pages where the block is used.The block configuration screen has two different save buttons – one "save fore all" (affecting all places using the block instance), and one "save as" (saving a new instance of the block, with a new name).
Block editing (containers/wrappers)
page 3 of the attached pdf
Containers/wrappers are blocks, but play a key part in setting up a layout/site structure. Their configuration consists in containing other blocks. I imagine the following will be sufficient to allow really varying site layouts, while still keeping it all in one type of configuration:
Add block
page 4 of the attached pdf
Containers have a button for adding more blocks. It brings a popup dialouge, where I imagine much the same interface as when adding fields in Views – there is a categorized list of already configured blocks, and you can search the list or filter by category.
There is also a link to the block builder (or something), where you can access module that allow you to build new blocks (such as Views and others). Once configured, the blocks appear in the list and can be inserted into a page layout.
Block configuration ("ctools context" scenario)
page 5 of the attached pdf
For the block configuration, I have two different scenarios. The first one is similar to how Page manager handles contextual information, and requires that every contextual data object is explicitly provided to the page/layout – if a node author should be used, you'd better load the node author.
This scenario requires a nice UI for adding more contextual data (for which I have no sketches).
Block configuration ("data selection" scenario)
page 6 of the attached pdf
The "data selection" scenario is inspired by Rules data selectors, rather than Page manager. I think the Rules approach gives a stronger and more flexible way of accessing contextual data, but also requires a stronger framework for data management. (Edit: Here's a screencast explaining data selection in Rules.)
In the data selection scenario all data sent to blocks belong to a defined data type. Text strings aren't just text fields – they are input for strings. Dates are dates even if they, too, may be inputted in text fields.
Essential for this approach is also that there is metadata connecting data types. Nodes have authors, comments have nodes and possibly parent comments. And so on. Data types also have simple properties, such as node title or user name (which are both identified as strings).
Phew. Here goes the UI for block configuration, "data selection" style:
Just as with input in Rules, it is possible to define default input widgets as well as overrides.
(I'm sorry that this description is so messy. Go check out Rules 2 and its data selection, and it will all be much clearer.)
In this scenario, you can add any block you wish, but you can't save it until you have provided each (required) config field with matching data.
Unlike the CTools approach, there is no need for a UI for explicitly adding contextual data – all derivable data will be at your fingertips.
Lots of new and old stuff here
Hi guys,
Specifically:
Itangalo, love your concretization of the whole thing with those screen shots. I like how you explain the different configure blocks options (5 vs 6) and agree that 6 would be more powerful (although more confusing).
I in the Add block modal, I don't understand the difference between the "Select type..." and "Go to block builder" buttons insofar that I can't imagine which type of blocks might go into each.
Generally:
I just wanted to note that we're going down a path that lots of other CMS / frameworks have tackled in the past. Typo3, for instance, has a strong concept of a tree (path/menu/url) structure of relatively fat page / layout objects with each page able to manage its own layout but inherit settings from its parent pages back up the site tree. Zope / plone also has this idea of settings spilling down to child objects in the heirarchy. Both use the "add a new text object in this region" metaphor in the front end. They pretty much punt on trying to keep all the little resulting objects managed/synced in a library. But the metaphor is simple, and users/editors understand it. You config/edit block X on page Y where it was defined first.
Of course we are going a bit further here, with context other than path/url being handled in a sophisticated, inherited way. We also have the burden / benefit of designing a layout system around drupal's relatively strongly semantic entity/content types "user", "event", "client", "school", "comment" rather than typo3's unsemantic "textblock", "image", "list" building blocks.
I think all of us are modelling this work on how panels does things, but there are a multitude of systems out there that we can model on. In any event we aren't inventing this out of thin air. When we run into issues, we can look at how other communities solved/stumbled over these problems. Or even when they decided that "solving" a particular problem was too complex or would be too much cognitive load on users, and decided to keep things simple
Clarifying "go to block builder"
Good points. I know that I, for one, lack any serious experience in other systems than Drupal – and having people with knowledge in other systems is an invaluable asset. Keep 'em coming!
Concerning the difference between "Select type…" and "Go to block builder", it is as follows:
Sorry for not making this clear.
BTW: I have now added a link to a screencast that (hopefully) explains data selection in Rules style (http://nodeone.se/node/987). It will hopefully make it easier for people in this thread to understand what I mean – though any final user interface will still have higher complexity than the [5] alternative.
//Johan Falk
**
Check out NodeOne's Drupal Learning Library! 190+ screencasts and exercises, for Drupal introduction, advanced configuration, and coding. Creative Commons license!
+1 on this is a well-trodden path & it's worth looking at others
Just joining into this discussion, because we have a started to see a change in customer expectations around the page creation experience. Lest we forget, often times, customers who want sites only care whether it meets their needs - not whether it's open source or not. We've seen Drupal lose out to some proprietary solutions, and so we've started to look into the systems we're losing to.
I've been the one tasked with doing the deep dive, and I've just spent the last 3-4 days spending all day looking at the following systems:
- SDL/Tridion
- Adobe CQ5 (formerly Day Software)
- Sitecore
- OpenText (formerly Vignette)
- Oracle FatWire (formerly FatWire, obviously)
- Squiz
After looking at all these, my first response is "Whoa - we in the Drupal world have no idea how easy it is to do very sophisticated page layout in proprietary products." Open source may rock, but in our case, the Drupal community has been totally in the dark as proprietary vendors reacted to Drupal eating their market from the bottom up. The way these vendors have responded is to create amazingly powerful ways for "average business content creators" to create sophisticated page layouts.
Some of the vendors have great demo videos. For example, Adobe has an amazing one here: http://www.day.com/day/en/resources/video/webcontent-incontext-editing.html
(may require registration to see, but I don't think so). The main video in the top center is the most relevant - though the other three below are interesting, too, and I'll have comments on Mobile in this thread, too.
I strongly recommend everybody participating in this group go look at that video. It should a) show us how far off we are from what our customers now are beginning to expect (in terms of level of sophistication), and b) potentially give us some ideas on implementation (e.g. inspector panels, etc.) I do note that a lot of the Drupal community depends on customers who build websites; and who often spend pretty big bucks building them. Those customers are going to be looking at Adobe vs. Drupal starting - now...
Whether that demo is "demo-ware" or reality, we've definitely seen customers NOT choose Drupal and choose CQ5 instead. And once they spend the money for something like CQ5, they'll work REALLY hard to ignore the difference between demo & reality...
I'm about a day from finishing digesting all the competitive landscape. After I finish, I hope to participate deeply in the conversation on this thread. Even more, it's highly possible we may have a customer prospect who is willing to invest substantially in funding the development of an interface similar to Adobe's for Drupal. The only catch: They want it by mid-2012 - not in D8 timeframe. Which is, of course, a pain.
I'll be back here in a day or two, and either react more to the specific technical proposals here, and potentially suggest other requirements, or solutions.
So, sorry to actually contribute so little technical content here; but hopefully I can bring a competitive perspective here that will keep Drupal from being blindsided by proprietary solutions.
I'd guess that the panels and
I'd guess that the panels and workflow are achievable. The literal hierarchical menu looked a bit like typo3. Any idea how that scales to k's of pages and whether you can reuse pages (or do they just get buried in a folder tree)? I'm a bit dubious about this kind of page-centric approach as it seems at odds with the idea of a dynamically populated site. Not sure that content scaling is often accounted for very well (e.g. Drupal itself and k's of taxonomy terms).
I've heard that we also face competition from the following:
We need more contextual information
The CQ5 video was really slick, but what it displays is pretty far from what we need for a WSCCI user interface – what it shows is basically how to input "dumb" content into static pages. We need a way for not only composing the content, but also connecting the content with context available on the page load – reacting to it both content-wise (such as contextual filters in Views) and reaction-wise (such as hiding/showing a block). Also, we need the ability to route the user to selected pages, depending on the context.
There definately are things we could (and should!) learn from CQ5 – I also encourage everyone to watch it – but we need to try to build something similar for more complex tasks.
Looking forward to it,
//Johan Falk
**
Check out NodeOne's Drupal Learning Library! 190+ screencasts and exercises, for Drupal introduction, advanced configuration, and coding. Creative Commons license!
More specific examples.
Thanks for looking at the CQ5 video.
A good example of the type of thing we must enable is to look at http://www.foxnews.com/ . Examine the home page, then note the Politics landing page, and the Technology landing page. This gives us several example of the more complex cases we need to build for. (Note: The foxnews site is a Drupal site, but was built using classic Drupal techniques.)
The use cases that we should support:
a) Note how the site home page layout varies from the other two (Politics/Technology). In Drupal, to build these layouts essentially required a combination of a Drupalist and a themer. The themer had to build a theme with appropriate theme regions, then the Drupalist defined the views, blocks, etc., and used some technology - Panels, Context, Blocks, or something - to put the blocks in the theme regions. Sadly, though, there was (probably) a difficult dance required between those two persons to build these three different layouts, and it took significant Drupal site building knowledge to handle all this. Other CMS products do not require this; "content editors" can build these layouts.
b) Note how the (top-to-bottom) block ordering changed in the "middle" column on the Politics & Technology links. Again, people expect that this kind of ordering is something that content editors must be able to do - not just site developers.
c) Though it is not illustrated by the Fox site, I can say that some Acquia customer prospects expect to be able to change these block / position assignments on a daily basis - especially "media" (e.g. TV, digital news, etc.) customers. They want to change the layout of the page in response to breaking news. So, e.g., if there is a big, breaking story, they want a specific (home / section-landing / ..) page to be quickly change-able to show a big "hero" image in one column across the top of a page, put a custom caption (or, e.g. views slideshow) under the Hero, then start a new multi-column section with various blocks under that Hero, and continue to change this layout as needed for the duration of the breaking news story - in order to have the highest impact.
d) Note that in the Fox (and other) site(s), there is a need for mixing the number of columns at various points along the page. Look, for example, how this page http://www.foxnews.com/scitech/index.html goes from 3 columns (in the main content area) to 2 columns in the "Latest slideshows" block at the bottom. I have seen this requirement in several other opportunities. Users expect to be able to drop a "container" in some place on a page, have the CMS do the appropriate (div) section break, then start the new column layout. They understand the notion of containers in containers, and dropping a container in the "right" place.
e) Yes, I agree that the CQ5 video only shows putting in "dumb" content - e.g. plain text. But (I _believe) it can also do smart (e.g. views-like) content, even though the video doesn't show it. And even more importantly, we cannot ignore the need to place dumb content on a page while we are building for the smart content! :-)
-jb
Given that timeframe, I'd
Given that timeframe, I'd hope you'd be looking to have conversations with the folks who already have existing, at-least-somewhat-complete solutions in Drupal - Context, Display Suite, and Panels. I know that Earl and I, at least, are interested in experimenting with many of the ideas being discussed here while still in the D7 world. All the better for the WSCCI efforts, since it gives us some real use & feedback before it goes into/launches in D8.
Agreed
I'd love it if Panels, Display Suite, et al could help "beta test" some of these discussions. That gets improvements "out there" sooner, both for the benefit of current users and to help us suss out issues so that what's in D8 core is the version 2 (or maybe 1.5) version of these efforts rather than a first-cut.
Also, Jay, thank you for jumping in! You're absolutely right that Drupal is in some ways behind the curve in terms of layout control, for various reasons, and the video above is a good look at what we're up against. At the same time, though, as Johan noted the entire "Drupal way" is built around defining rules for content, not content itself, so we need to be careful to not put "I'm used to Dreamweaver and laying out each page individually" before "we want something fast, robust, responsive, and logically consistent".
I look forward to the rest of your research!
Storify
Just looking at storify.com which is kind of a CMS for tweets and other remotely hosted content. The layout options are minimal (though drag and drop) but a very slick interface for composing a page from pieces of dynamic content elsewhere and adding pieces of static text. The publishing workflow is simple but also nicely done.
Drupal UX flexibility
My thoughts.
I tried to sketch a kind of crazy layout of crazy website.
1. Layout flexibility
Layout flexibility means configurable arrangement of regions.
Regions are needed only for one purpose: to arrange the blocks.
We (site builders) need 2 kinds of regions: those arranging blocks vertically, in column, and those arranging blocks in row.
The second is challenging a little. Best known up to date are the grid themes in which we can configure how many grid cells form the width of the block (Acquia themes for example). I would love this functionality without limitation to grid cells scale. Width scaled with em could be the best.
As far as I know form my experience with Plone project, it is possible to obtain this kind of flexibility if "main page" template is hung as high as possible in the DOM hierarchy. In Plone project, HTML header of any page is a wrapper of the "main template". Even in Head HTML section they have some slots. You can create and fill slots using three simple notations called TAL, TALES, METAL. I remember a handful of variations of the "main template" I created for various purposes.
Library of layouts
Layout = arrangement of regions.
Themes could provide standard layout, as they have now, for immediate use. However, it is not necessary in general. It has to be possible to create new layouts (regions arrangements) easily. So, in the sketch above I placed a tool for "New layout".
In this way we can have a Library of layouts.
Theme
It follows from the above that theme should be a decoration of the layout.
In the simplest cases, contributed theme could be a decoration of a core theme. If color module is used as standard, the core theme should have more options than Bartik; minimum is that of recent version of Pixture Reloaded. In more advanced cases, contributed theme could also provide 2-3 exemplary layouts to the layouts library.
2. Blocks flexibility
I rethought several times the issue, including a concept of Super block, and came into partially conservative conclusions.
Actually, Drupal has a lot of ready-to-use blocks. It's OK, and now a step further should be done:
Library of "Block types".
It could function similarly to the list of content types.
A lot of projects going into this direction proves the demand. So, integration project should be established with the aim to reduce complications (variability of them), ensure flexibility and reduce resources consumed by them. And - I hope - do deal effectively with cache problems!
For example such modules ass CCK Blocks, Nodes In Block, Node Blocks etc. could be integrated into one multiblock for display a field, teaser, or full particular node. Probably it would require one module instead of several ones, no CCK infrastructure,...
Exact set of functionalities o such block should be widely consulted in order to secure flexibility, and to avoid the excess characteristic for projects transfering all unnecessary node's functionality into the block.
The same for RSS block. It could enable users, groups, maybe taxonomy categories etc. have their own RSS aggregates.
Of course, it is possible to build such aggregation machines using Views 3 (I have built some), but it is not a game for every site builder.
The library of block types should contain also HTML/text block, Menu block, etc.
Library of blocks
It could contain some ready-to-use blocks, as it does now.
Workflow for these libraries is obvious: Create a block of particular type, and place it in the Library of blocks. It can be dragged and dropped from this library to the layout chosen from Layout library. Save resulting Page.
Page = Layout filled with Blocks.
I modified one of my previous sketches to illustrate the idea of the library of Block Types, together with the Library of blocks.
Here the second key element of the block configuration - the location is still implemented as a drag and drop interface.
Context
The mess of contextual filters begins in permissions/roles system, eventually extended by contributed modules manipulating node access or even field access. Some of them conflict with others. Views and related modules provide lots of contextual filters including those handling relations and attachments. Some plugins to Chaos Tools often cause errors in Views or work incompletely. New Entity types like Fields Collection are even worse in this respect.
Organic Groups have own Context configurations.
Recently Context module imposed another layer of complexity at the attempt to collect much more context "dimensions", including menu, taxonomy vocabulary and categories etc. Most of them are also handled by Chaos Tools and Views - straight way to cause conflicts or ambiguity and confusion.
For UX, most important problem seems to be that both content and location of the blocks are context dependent. So, sometimes there is a double work (for example "logged in user" from Chaos Tools is often the same as Authenticated User from permissions system and from Context module). Often confusing or disorienting what is filtered by what. Second, there is blur distinction between content and context, esp. in the cases where the content is a response to Views (or other) query containing explicit or implicit contextual arguments.
All above make reasonable argument for the project of central context system, providing unified and simplified context configuration for blocks. However, discussions elsewhere indicate that it is not easy task, at least in conceptual layer. Therefore below are my remarks as to implementation strategy.
Block configuration
Three elements of block configuration are content, location and context.
Block level. Actually, context configured at block level, and is implemented as Visibility Rules in vertical tabs. If plan is to keep it in future Drupal, I suggest to extend the number and content under vertical tabs slowly, step by step. Simply, I am afraid of possible inconsistencies and errors.
System (?) level. Another logic of context configuration is recently proposed using Context module. For placing blocks, it looks like that below.
Inconvenience here is that logic of placing blocks is additive instead of subtractive. It requires remembering exact configuration of more general page. Better is to use drag-and-drop mechanism discussed in this thread and shown in sketches, as it eliminates this inconvenience.
Problem I didn't thought in details is how to divide the context elements to those configured at page level and those configured at block level. Probably it would be reasonable to configure site-wide context as default, and permitting some elements' configuration to be overriden by Users (esp. language), and by admin (page configuration and block configuration). Such approach imposes a logic similar to roles/permissions system to the context configuration system. There is a danger to cause extra complexity, and the chance for unification at the same time. Seems to be tough problem.
Page library
I'm not sure if we need Page library functioning as the support for UX management. Instead, I propose above a Library of layouts.
Another story is the libraries for bulk operations. If I have - say - over 8,000 Authenticated Users, 85,000 nodes, and huge EuroVoc thesaurus, the mechanisms for bulk operations for all these Entities are inevitable.
Components library
Ockham razor rule suggests that Components library should be implemented as Blocks Library. For example, logo block and site name block could fill standard header region of the core theme. However, it could be possible to place Search form block, Sublogo block etc. in the same region. Imagine how easily it could be to design the sections of newspaper.
Also, safe step by step strategy of implementation could be easy, as some actually fixed page elements, as footer, menu/navigation elements could be kept unchanged in the meantime. Also, attached elements as links, flags, comments etc. could be kept unchanged until better solutions are found.
Summary
Detailed view at the concept of Page & Component library suggests that page library should be implemented on the basis of Layouts library, and Components library should be a subset of the Library of blocks.
I think the solutions presented here enable to shorten learning curve of new UX configuration and to plan safe step by step strategy of implementation.
Grouping Page & inheritance
Enjoying this discussion. The initial sketches bring back something like the initial sketches of d7ux. It’s exciting!
Discussion
Thinking about what these groups of pages might be it would seem that they are sets of selection criteria (a blog section it would be the blog node, blog listing page, blog archive page) and reactions (display the most recent blog comment in the second sidebar). So groups of pages would be pages that inherit from a set of (overridable) defaults. In this model the “Page Library” might look more like this.
The pages would be grouped by selection criteria and configuration they have in common.
I think this can be further divided into two issues. One of them being the issue Jeff Burnz raised (http://groups.drupal.org/node/160144#comment-539619) and solved in the same post. I think the model suggested by a few people of page manager handling its Panels "site template" is a good fit here. So we have a global default page with settings for things that wouldn’t change much (an example might be the contents of the header and footer).
The other is the issue Itangalo is providing a solution for “Block editing (containers/wrappers)” http://groups.drupal.org/files/config%20UX%20sketches%202.pdf. I see this issue as how we handle editing of regions. One of the few (only?) thing core blocks do better than Panels IMO is the way regions are handled. In core blocks a region is a cascade of conditions. I have selection rules (menu in sidebar site-wide, view in sidebar only on one page) and they combine together. In Panels a user has to configure pages on a one by one basis. In the sidebar of this page have this, in the sidebar of this page have this. Mini-panels provides a way round this but does not seem as intuitive as the default Drupal way of handling regions.
As such I think having as much configuration as Itangalo does in “Block editing (containers/wrappers)” might not be necessary. I think a blocks positions, whether is appears, should be config that is handled by the block not be region it is contained in (not at a code level but at a conceptual level). A users hits the edit page button. The configure they can add/remove/reorder blocks from a region. This can happen on a page, a section, or a site-wide basis. To the user it should appear that they are editing blocks in the region, not the region itself. Maybe the reason I am confused here is that some of the ideas in “Block editing (containers/wrappers)” seem new to me. I don’t quite get the idea of “special cases”.
Research
I really like the idea of researching what others are doing in the problem space of site building. We should be aware of some of the great work going on at http://groups.drupal.org/cms-feature-reviews where other CMS functionality is discussed.
Summary
I think a lot of the initial questions posed have received good answers and food for thought. The areas I was not quite as clear on from my reading all the above (a few times!) was the issues to do with grouping pages and how a system of inheritance between pages might work. These are the areas I tried to give my two cent on above.
Client-driven interfaces
I heard a REALLY interesting presentation the other day that's highly relevant here.
Mike Reich just finished building the new http://fcc.gov . As a strategy, he decided to take the following approach:
On the main FCC.gov site, he used a mix of content coming from drupal the "normal" way (e.g. HTML sent directly in the page) plus content pulled by the browser via JS.
However, he created a separate site - see http://my.fcc.gov - where nearly all the content is pulled via JS snippets. While this 100% client-side assembly is better suited to the nature of this subdomain, the basic principle he's using inverts normal Drupal on its head (and makes it more aligned with the direction web programming is headed): Putting everything on the browser, which grabs data as and when it's needed, changing the role of the server to an API-driven content store.
I've commented on this in the REST routing group (and am about to start a new thread devoted to it), because there are back-end structural things to think about.
But from a front-end UX perspective, it's worth considering this approach. If you didn't see it at the my.fcc.gov site, you should really watch the video by Mike where he shows how the my.fcc page works. There are a couple of things to note:
IMHO, this is brilliant. It's also a huge start on what can be done to implement what we've been talking about in this discussion.
I note one other thing: This same aspect enables content to be "personalized", because the client can be sent JS that embodies a query based on context. E.g. get the client to lookup a cookie that contains information about the end user (or his / her identity), send it back as part of the content API request, and get back / display content that's different in block A for user 1 than the same block for user 2. This might be a way to get conditional, per-user content without the user necessarily being an authenticated user.
Really nice
Damn, that's a good looking demo. Thanks for the tip!
squarespace 6
Don't want to distract the conversation, just thought it would be interesting for assesment of what competitors do to look at their solutions for these problems. http://blog.squarespace.com/blog/2011/10/21/squarespace-6.html has a pretty impressive video of in-place grid based layout editing and page / content editing mixed in one.
If....
Panel's UI was cleaned up, and if it had more default layouts available, and some of the terminology was cleaned up - we'd have this in Drupal.
That's the idea
By bringing this functionality into core, we can reduce our usage of nouns by at least 40% and eliminate some of the uglier architecture and UI issues that exist to hack around core's limitations.
That is, of course, easier said than done. :-) "Cleaning up the Panels UI" is, in essence, what we're trying to do here. Or at least re-imagine it.
wow
Just discovered this now.
This is pretty impressive, and in line with what I have seen from other Website Building Systems (I understand Squarespace is a service, not a software one can download).
But no mistake, this is what we are competing with, and on an increasing level so.
Life is a journey, not a destination
Sweaver
Now contrast that with http://drupal.org/project/sweaver and you can see how even with D7 we have efforts to make things that are similar to squarespace.
Imagine what we could do if we had D8
Software Engineer @ The Nerdery
Huge thread :) Have a
Huge thread :) Have a crosslink: Jay Batson outlines a persona that should be able to handle Pages and Components: http://groups.drupal.org/node/185709 see the second PDF (was presented at #badcamp), did anybody in here attend? :)
Great pdf
I second yoroy's recommendation of checking out batsonjay's presentation.
A Role Oriented Perspective
I think @batsonjay raises some very good points about looking at things from the 'outside in' – especially from the point of view of the content manager user.
To complement the persona perspective, I think it's also useful to define user Roles as precisely as possible. To clarify this point, I've prepared a short video to explain exactly what I mean by 'Roles' and why it is so important to approach any UI design problem from a Role Oriented perspective.
I’ve been studying this (rather long but very interesting) discussion quite carefully and am looking forward to adding some more thoughts about this fascinating UX challenge. I’ve also been conducting an extensive (but not exhaustive) usability review of Panels and Page Manager and am currently in the process of producing a set of videos to summarize my findings there. It may or may not be directly useful to this thread but if anyone has suggestions for where to post please let me know. Thanks.
Update: the videos that summarize my Panels UX Review are here: http://myplanetdigital.com/blog/helping-increase-drupal%E2%80%99s-compet...
Michael Keara
User Interface Systems Architect,
The User Advocate Group
In an attempt to get this
In an attempt to get this discussion moving again, I discussed some basic ux scenarios with @Crell that we should explore UI designs for: http://groups.drupal.org/node/199938
Round two of sketching and mockups is over there and you're all invited :)
Per-page layout module
Following up on @batsonjay's post above, we've started work on a module for a client that will provide working code implementing some of these concepts, but from a different UX and architecture direction than panels/panelizer. More information is available at http://drupal.org/node/430886#comment-5460758. We'd love feedback from the community - our client is interested in using this project to help prove some of the concepts that are being talked about here.
If you want feedback on the
If you want feedback on the UX part of this, we'll need screens, sketches or demo sites :) From your comment in the other thread:
All make much sense to me, but only at the same level of specificity. I'd need more detail to be able to respond in more detail. How can we set that up? Thanks!
Sitefinity
When developing with other CMS's the one that gives me the most angst is Sitefinity CMS from Telerik. Initially I get all excited because their page management is a lot like how I imagine Drupal would have been like if it had built in Panels from its very beginning.
I usually want to throw the entire CMS away whenever I need to create custom content types. I'm too spoiled with how effortlessly Drupal handles that problemset.
I would like to encourage everyone to watch this video (start at the 30 second mark) to see the layout-first approach Sitefinity takes.
http://youtu.be/gCnYb4MbYD8
Are you back?
Did you just think that all they were doing is having a panel layout with a bunch of node references and had Panels in-page editor turned on?
Yea, that's what our future could be.
Software Engineer @ The Nerdery
Template Builder
I don't know if this is in scope but if we were to implement the concepts of "panels in core" and "superblocks" then I don't see anything preventing us to build pages like the Template Builder shown here:
http://youtu.be/6YIC3B9khD0
Software Engineer @ The Nerdery
D7 Layouts Demo
Hi All, follow up to the post I did above and the Layouts announcement from Dries, we've put together a screencast of the latest version of our approach to per-page layouts. (This is a working title for the module, we'll be changing to something final in the near future).
https://vimeo.com/37867040
Background on what we're trying to do is here: http://drupal.org/node/430886#comment-5460758.
Thoughts and feedback on the approach will be really helpful. Next steps are to build out functionality on this framework, including:
We're hoping to do a BOF at DrupalCon to walk over the final version of the module as well as start a conversation about where this could go for Drupal 8. Let me know if you are interested.
I'd definitely like to attend
I'd definitely like to attend this Bof, the module looks great.. A lot of potential there.
IMO, let's not design for 100% layout control
I've been thinking about this a lot, because I'm hearing a really fast jump in the number of customer who want this kind of function. The good thing is that it has provided me tons of data points into what (I think) people really want Drupal to do. (Whether this results in "insight" is another thing... ;-)
And I think the key is this: They don't want complete GUI layout control - just control of a "Content Area".
This is the traditional Sidebar first/last & center content regions. I think it's the stuff you'd get if you told Panels to "turn off regions" in Bartik - e.g. the stuff that's after the header-style theme regions and goes to the footer (and of course is bounded by left/right page gutters). Just to be clear, this can include more than the node body, since this includes what might normally be theme regions that contain blocks in sidebars, etc.There are really only a few key observations that show up over and over in conversations:
I hear this from nearly every size customer (except the one-person, blog-style user, who wants a GUI to control absolutely everything on the page). In general, as soon as site owner is big enough to have somebody in charge of site design (who knows what they're doing...), they trot out the above requirements.
I think there's a big implication arising from this. It may sound elegant to create one layout system to handle everything from upper left corner to lower right, that's usable by anybody from Drupal site builder to content creator. But I personally think this would be a really, really bad idea. The huge number of capabilities that such a layout control would have to provide means that the UX will by its nature be very extensive - and complex.
This would be bad. Drupal is full of complexity; we need to bring simplicity to the 90% use case.
So, IMO, we need to focus these D8 layout control improvements on those people who need to live with Drupal day-to-day after developers/designers hand over a site to a customer. The UX we give Ellie to fill up the Content Area should be REALLY gorgeous and powerful. Let's spend our effort & time making this amazingly, mind-blowingly awesome - and worry not a moment about making a full-page-layout GUI.
I really, really pray we can focus on this, blow the socks off every other WCMS, and wow both old and new Drupal users.
A key - and possibly controversial - implication that I believe arises from all this: We should not try to meet the needs of that small "blog user" type customer, who wants full layout control. If we are honest with ourselves, a) that person will (should?!) end up on WordPress because it's so purpose-optimized for this type of user, and b) the vast majority of Drupal sites out there are at places where the above requirements are going to exist.
Ok, maybe this sounds like a rant. So,
</rant>.I'd like to echo that I've
I'd like to echo that I've heard the same requirements from Drupal users. I believe it is an important use case to support. However, I think of it as an additional functional requirement (vs maybe having the wrong architectural approach). Thanks for bringing it up, Jay.
re: IMO, let's not design for 100% layout control
Jay,
So I 100% hear what you're saying here, however there are some things at play we need to consider.
This does increase the complexity of building layouts, however the same arguments for headers and footers are going to be made for sidebars, and we'd be better off just addressing the problem space instead of trying to treat the various region groups as separate concerns.
Hopefully that's clear, if not I'm happy to explain more. In short, I think we should provide a full page layout tool (satisfying the needs of your blog user example) while providing tools to prevent change in regions under certain conditions to satisfy the needs of "everyone else".
Eclipse
I understand...
... your desire to unify the problem space. I'm not against the goal per-se; I think you do have, and need to solve the actual divergent technical problems you cite.
I just want us to keep focused on the UX for the 80% (90%?) use-case: That moderately-skilled, Drupal-untrained users have a highly-usable UX that gives them real power to affect a limited area, and that modifying the layout of other areas is actively discouraged among site owners.
Let me be clear: I have full confidence this fine collection of Drupal devs will create a amazingly-engineered solution, and probably solve all your technical problems. And if you can solve the whole problem in one UX, cool.
But I'm guess if I'm being honest / transparent, I'm worried that building a UX that solves this whole-page layout problem will lead to the typical Drupal engineering-led solution - at the expense of meeting this 80% use-case end-user requirement.
So I guess I'm trying to drag this group towards making huge allowances for the latter. If we do, I'm betting the actual end result might in fact have the correct usability / engineering balance. :-)
We're probably both right to a degree, here....
I 100% agree with those
I 100% agree with those statements Jay, and I don't want the typical Drupal engineering solution issues we normally have either. That's why I'm begging for js/ui experts.
I fully admit to wanting to solve the whole problem space, BUT if I have to take an 80% solution in order to serve the best interests of Drupal as a whole, I certainly will, so hopefully that puts both of us on the same page here.
I think we already were...
... on the same page.
I just like posting on g.d.o. It makes me feel useful. :-)
I agree that this is an
I agree that this is an important use/business case that can make a difference to Drupal’s acceptability in larger corporate/organizational scenarios. It’s good to have the requirements for this target area clearly summarized.
The question of degrees of control required or permitted for these scenarios points once more to the importance of taking a Role oriented strategy to UX design. In this case the general ballpark of Roles is content providers/managers in a large organization. In other words, the target users have a fairly specialized task set - hence they have restricted requirements.
In smaller scale scenarios, the Role boundaries may blur significantly– the content manager may also be the designer and sometimes even the site builder.
The blurring of responsibilities for a given user doesn’t mean the Role distinctions don’t exist. In practice it may be that one person has multiple Roles (this is why I don't like the use of the term 'roles' to describe sets of permissions which don't change for a given user). The Role articulation is still possible and necessary. The scenario described by Jay just amplifies the importance of keeping a clear focus on who the target user is.
To make it work for all scales of deployment, there has to be a smooth cooperation between the Roles of site builders and content managers. For me, that largely means moving towards a ‘pull’ model – which seems to be the principle behind the core context approach.
What does that really mean? As I see it, when content is created before the IA is defined then it ends up being a ‘push’ model. In Drupal we often create nodes and ‘push’ them out to the site via the associated menu links. In the case of Views, we also can define pages in the View settings and ‘push’ the content out that way. In both cases the IA definition is a ‘by-product’ of the content creation or retrieval task.
But when the IA definition precedes content definition, it provides a spatial context (read easy to grasp for non-trained users) in which to pull content. In other words, create the ‘pages’ first - and then place content (or content mechanisms such as views) into those places. As we all know, Panels uses Views and other mechanisms to pull content into a location (url) defined in the Page Manager. This supports a clean distinction of Roles.
When combined, the principles of Role-oriented design and the pull model open the door to significant opportunities for a powerful UX design strategy. I’ve just posted a video and some articles about the ‘IA definition first’ concept based on a project I did a year ago that took advantage of this principle.
Michael Keara
User Interface Systems Architect,
The User Advocate Group
Great use cases
I really think you have nailed several great use cases.
But with making these possibilities available, also creates new challenges. Particularly how this wanted flexibility also can be combined with making sure the site is still easy to re-theme and easily can be adapted to various display devices.
While Ellie certainly are capable of making adjustments to the content area, I'm not so sure most Ellie's also will be able to understand how her changes will affect how the content is viewed on all the display devices tomorrows web will serve.
I am quite convinced these challenges will require new types of roles as well as tools that will adapt much better.
Responsive design is in my mind just a temporary "fix" because todays web is designed for desktop computers. For us to really create a platform for tomorrows web we can not rely on responsive themes to solve that issue.
So, not only do these "blocks everywhere" need great access control, they also need to have smart enough features to adapt to the display they will be shown on (if at all for some) and of course also play well with the theme layer(s) among other things.
--
/thomas
T: @tsvenson | S: tsvenson.com
Device awareness
Thomas -
In my discussion with all the various customers / prospects (that triggered my post above), the "Ellie" person is highly aware of device changes.
In fact, often the Ellie role is driving mobile. If you read the persona description (which is a composite of a few dozen customers I've met with in the last months), Ellie:
- Works in Marketing
- Is responsible for helping drive "conversions" (success) with the site
- Knows the analytics data for her organization, and the visitors
- Sees the growth in mobile
- Wants to make sure "... the new CMS will handle our mobile visitors."
Now to be clear, most Ellie's are just thinking phones - and a few are becoming tablet aware. But they all have definite intent to handle the mobile case.
In the most recent work we did for a large enterprise building a mobile site (that I bet > 75% of the US will use during 2012!), we knew we needed to handle the "not all computer-browser content should show on the mobile device" problem.
We subcontracted the construction of Ellie's layout tool to Mike Reich, who built a tool that permits varying content to be delivered to mobile-sized viewports. See the demo video at http://vimeo.com/38175161 . Note that the actual content is being delivered to a responsive theme.
So, in summary:
1) Ellie does think about how content view might need to be modified for different display devices
2) We've already done some great work on unifying responsive design with differentiated content
3) We did it by block visibility changes
Agreed - its all about responsive+
I think responsive design is great. It makes total sense, but its also only a start to solving multiple device rendering, not an end.
Fundamentally, the use cases for using mobile are often very different than a desktop website. The approach we took here was basically giving the option to remove or add functionality that is specific to the mobile experience.
Think of it as both removing stuff that's not needed to slim down the page, but potentially adding blocks that only make sense on mobile.
Giving the user more control, within bounds, can only improve the end user experience. CSS is fundamentally dumb and only works with what you give it. Content creators know better than CSS what their users need to see on mobile.
Tomorrows display devices
With responsive design that is commonly used today, it is not that difficult for Ellie to have a good idea on how the content will look on each design. Especially since if its properly implemented will automatically adjust when browser window resizes.
However, when looking forward, responsive wont be able to cater for serving the content more than as a shortcut.
With HTML5, better separation between content, layout, display etc will allow for vastly different design and UX depending on if you access a site on mobile, tablet, desktop or even TV. I envision they will have very different feature sets to allow the audience to take full advantage of the device they are accessing with.
The audience will also want to easily switch device. So, in the office you normally use you laptop/desktop, where you can tag content. Then when for example traveling you access the site from your tablet/mobile and can use that tagged content as a reading list.
The web will be more dynamic, more interactive and more like applications where you manage content you want to digest on suitable devices or when you have time (such as on the bus, train etc...).
It will require new skills and roles.
Ellie is a content creator and I think in the future she will not so much have control over the layout. Instead she will get much better tools to be able to mash together her content with related content. Tools that not only will help he create better content, but also give the audience a better UX.
--
/thomas
T: @tsvenson | S: tsvenson.com
Disagree on Ellie not having ...
... much control over layout and devices.
I can name 3 "real life" Ellies I'm working with now. They all care about doing a good job, and they all care about both layout, and different layouts with mobile devices.
And this is why Mike (and Jay) built the tool here that provides Ellie with some layout management for mobile (http://vimeo.com/38175161 ).
To be sure, we're only giving them the limited control within the bounds I described in the post that kicked this discussion off. But, they do care, and want layout control for different devices.
On smaller sites with few
On smaller sites with few Ellie's then yes she can have that role as well.
However, for bigger sites with tens, or hundreds, of content creators it wont work if each content creator has too much freedom to tailor the layout to their preference. It will simply be impossible for all of them to also have the same idea of the bigger picture.
--
/thomas
T: @tsvenson | S: tsvenson.com
Re: On smaller sites with few
We've implemented this approach on a client site with about 200 Ellies. It works because the bounds are well defined, with a solid set of defaults for users. Better yet, the conceptual model for page building 'just works' so didn't require a lot of training. The sitewide branding is kept consistent because we don't let people have control over critical page elements like the nav/header. We were delighted to discover that users generally don't want to create crappy looking pages. For sure, it takes some sensible block/template theming to keep everything looking good, but scaling to large numbers of content creators hasn't created any brand management issues, other than cleaning up the odd page here and there.
Yes, but as you say it "works
Yes, but as you say it "works because the bounds are well defined". What are the typical layout changes these Ellies are able to do?
--
/thomas
T: @tsvenson | S: tsvenson.com
"Bounds" can be thought of in two ways
"Bounds" can be thought of in two ways, defaults and constraints.
Defaults provide a canvas that's pre-populated with content blocks for a particular content/entity type. These are created by the site admins, and create a base from which users can go from. Most users never deviate from the defaults, even though they can, because it is basically what they want. Generally, when the display needs to be different than the default, its because the content requires it and the user makes the determination to deviate in some way. Example: a really long content page where the footer blocks get lost well below the fold, so the user has the freedom to move them to the sidebar.
Constraints are limits upon what a user can do, and this really falls into two categories. The first is limiting what they can put on the page, and this is covered by the built-in block permissions scheme. The second is controlling where they can put things on a page. We've taken a fairly permissive approach to this, basically giving the user free reign over the '$content' area. They have a set of pre-generated layouts to choose from, and the ability to put blocks (that are allowed for their user) into any content region.
We've noticed a couple of benefits from this approach:
Hope this helps provide a some context.
It sure does. We are
It sure does. We are basically talking about the same thing. Difference being your describing current use cases, while I'm more looking into the future and how this will change.
Yes, content creators will get better tools and possibilities to adjust how their content is presented. It will be within bounds as you say.
What we need to find for Drupal is how to best make this possible. It will require finding a balance on the granularity on permissions for what different users/roles can do with the new blocks, as well as how they play together to make sure its possible to create flexible designs and layouts.
--
/thomas
T: @tsvenson | S: tsvenson.com
Great updates to this discussion
Yes, for most sites designs you need a basic set of 3 to 6 specific whole-page layouts ("Panels pages"). Once you have those, most subsequent variations are layout variations on this content area ("Display Suite"). There can be 10 to 50 or 100+ of those if you want, but after the first 10 you quickly hit "one-off" territory ("WYSIWYG").
Looking forward to meeting you all at http://denver2012.drupal.org/bof/d8-layout-initiative-ux :)
What happens to entity view modes?
Ok, so this touches on a topic I've been thinking about, but haven't been sure where to mention it, or if it's already been discussed without me noticing. If this is the wrong place to bring it up, please point me to the right one.
In a model where we have page layouts and ability for blocks to nest, do entity view modes get subsumed by this, or remain a distinct concept? The way entity view modes (I think we currently call this "Displays" within the "Manage Display" part of Field UI, though that term is so overloaded) currently exist, they are abstracted from pages. I can define what fields to show, in what order, and with what format settings, for my Article nodes in "teaser" view mode, and for my Event nodes in "teaser" view mode. Depending on your point of view, doing this is a "site builder" task or a "content editor" task. Display Suite adds more sophistication to this process than core's Field UI. Separately, I can configure a View to show a listing of node teasers filtered in some way (but for this example, suppose article and event nodes can both be returned, interspersed, in the same listing), and configure this View to show in some block on some pages. I can of course create multiple Views, each in a different block, and any given article/event node may appear in whichever subset of those, as per each View's filters. All of this Views/block setup seems like "site builder" work to me rather than "content editor" work. My point here is that the arrangement/settings of fields within "article node teasers" / "event node teasers" is not tied to any particular block or page, but rather is tied to the entity/bundle. In some sense, arranging how fields should display within an entity view mode is very similar to arranging how blocks should display in a page/layout. But in another sense, which I hope I just made clear, it feels quite different (unless I'm just not being visionary enough).
If we take what batsonjay and yoroy just said seriously, then that suggests it's more important to make a really nice UX for arranging fields within a view mode than it is to make a really nice UX for arranging blocks in a layout/page. Of course, if we can make a really nice UX for doing both, then great, but can we within the time we have?
A challenge that pops up, however, not so much with node teaser listings, but within pages displaying one primary node, is that the content editor wants to put some of the node's fields somewhere different than the primary content area. And I don't mean just splitting the primary content area into columns, I mean into a full-fledged region, like the left sidebar, the same left sidebar that contains full-fledged blocks like search, navigation, and a View of "related links". And, according to HTML5, the <article> tag needs to be around all of the article, not just a part of it, so now the rendering of that tag needs to be handled by some layout that spans multiple regions rather than by an entity template. So this starts pointing to benefits in integrating fields-within-entity-view-modes and blocks/layouts more tightly. And does that mean that we get forced into supporting "variants" (from Panels) in core (since we have to allow field display settings to vary by node type, since that's what Drupal 7 core can already do)?
Or, do we somehow make the left/right sidebars into a different kind of region, that need to integrate with entity view modes, while letting generic block layouts not need to deal with that? According to batsonjay, that would solve the 90% use-case, even if as engineers we feel less good about the less generic solution.
I think it would be great to approach these questions initially from a UX perspective, and then after figuring out what good UX is, ask what the engineering implications are, rather than assume that fully unified and generic blocks will magically turn into a good UX for assembling them.
Looking forward to fun discussions in Denver!
Very glad you added this
Very glad you added this right here effulgentsia
Yes (for the editor role)
Yes! I think of this as nested regions. The page builder (role) defines what containers there are for the editor (role) to put things in.
The 80% variations needed on full page level is easily covered with say, 5 given layouts. And I'd imagine the variations I need there are more expressed in rules/permissions-like conditional handling of what gets shown when and where, and not in an additional 20 fully baked templates.
It's going to be fun :)
For some value...
... of the word "fun". :-)
Did you see this?
http://vimeo.com/37867040 ?
This handles the "blocks" problem ok. But it doesn't take us down to fields-in-nodes.
Non-drupalists don't know fields
I would argue that it does - fields should just be blocks.
Keeping the non-drupal expert in mind, the field/node/entity technical details don't matter and shouldn't be exposed in the UI. If you do, you then have to teach every user what a field is, how to use it - basically a new mental model for content rendering. On the other hand, they already know what 'blocks' of stuff are.
Say I want to add a byline to my article - that should be a 'block' under the title, because that's what it looks like on the page. I think we quickly get into the trap of teaching people 'the drupal way' when that actually means teaching them how to do something that's unintuitive. As a basic user, I shouldn't have to understand anything about the internal content model to get the page to look like I want.
Agreed
This makes a lot of sense to me. As I understand it, node/entities act merely as collections of data (fields) for the purpose of content entry and management. As you point out, the data from those fields is delivered to the screen through blocks (like everything else). The original containment mechanism of the data (the node/entity) is irrelevant to the screen display, except as possibly some contextual factor.
@effulgentsia, your questions were very interesting. Does @mjreich's response answer them or are there other factors to consider?
Michael Keara
User Interface Systems Architect,
The User Advocate Group
OK...
This seems a good a place to respond to this thread of consciousness as anywhere... I'll address Effulgentsia's specific questions about display modes separately.
I just want to stop everyone right here. The notion that we can ignore the entity that contains fields is completely false, suggesting otherwise is detrimental to the entire conversation and will side track us for a very long time. I have EVERY intent of putting contextual management into the administration system that core uses. I will be making sure we have mock ups surrounding it, and that the block system recognizes it.
Why?
You want to display a field? great what contexts do you have? oh you don't know? well then how do you tell if the fields you have available to place are for the node you're currently viewing, or your current user? I can't just lump all fields together, we need some separation. What if we're dealing with multiple nodes? What if we're dealing with multiple revisions of the same node? We need a contextual selection (and more) system in order to handle these situations and MANY others.
Yes field output could certainly be handled by blocks (and in my view should be) but you have to pass an entity context to them in order to render the appropriate data. The second you have more than one of the same type of entity/bundle you're going to be kicking yourself for saying this. If you don't use drupal that way, that's fine, but a LOT of people do, and ignoring them because you think it will make things simpler is the path that gets ME lynched, so... let's not do that. :-) Anyone who feels otherwise I am VERY VERY VERY happy to directly address this with you via skype, or in person next week at Drupalcon. What I am uninterested in doing is breaking down into a bikeshed on the issue.
A clarification
Kris,
Just to clarify one one point - the phrase "the original containment mechanism of the data (the node/entity) is irrelevant to the screen display" could have been more clear. I was talking about the outside perspective of the non-Drupal expert user who shouldn't be concerned with the internal mechanisms of entities and fields. The comments in this thread raise some interesting questions about the way in which these such users might perceive nodes/entities that can be 'split' into different parts. Worth pondering I think.
Your architectural strategy sounds bang on as an underpinning to a strong UX. But the UX is a tricky thing to talk about: all good UI effectively becomes invisible to users because it allows them to focus on their tasks and not the usability obstacles. Failing to make the UI 'invisible' is how UX designers get lynched :)
Looking forward to resolving more of these inside and outside perspectives next week.
Michael Keara
User Interface Systems Architect,
The User Advocate Group
I'm looking forward to it
I'm looking forward to it too. It sounds like we're on the same page here.
I think I like where this is
I think I like where this is heading. I've long been willing to move display settings for a field out of $instance ($instance['display'][$view_mode]), and into a standalone "display" object, holding the display settings for all the components of an entity. Wiring that with "layouts" is the on-steroids version.
A couple notes, though :
Performance-wise, "a field = a block" means "each field gets rendered in a separate (HttpKernel) subrequest". A listing page potentially means 10s of entities and 100s of fields. Do you think the "subrequest" concept will scale that well ?
We (read : effulgentsia) had to fight hard in D7 to gain back some of the CPU percents we lost just by moving from
print $body_as_stringtotheme('field', $node->body_as_field)...render() in node.tpls have an important side effect : whatever customizations you made in your 'full' view mode and/or your node.tpl, adding a new field to the node type, either consciously through Field UI or "unknowingly" by enabling a module that happens to add new fields, "just works" : the field is visible on node/%nid without you needing to navigate to 'Manage display' and explicitly opt it in.
I think we very much need to preserve that feature. Can there be such a thing as a "default dumping region for the components of an entity that don't exist yet at the time you configure the layout" ?
View modes are not only HTML : search, rss, pdf... for those, the notion of "regions" / "layouts" might or might not apply.
As others pointed, there still needs to be a distinguishable difference between "overall page layouts" and "layouts for an entity in a given 'flavor' (currently called 'view mode')", simply because /node/%nid is not the only output for a node. Entities are listed, displayed in arbitrary spots defined by admin config or hardcoded in module code... View modes are still needed as a layer of indirection.
View modes are defined by the places where some module code somewhere decides to use them - i.e 'teaser' is "the view mode node.module uses on /node"; "full" is "the view mode node.module uses on /node/%nid". Layouts are user config land, might come and go, a module cannot hardcode the name of a layout in its code. A module says "I'm about to display this 'flavor' of the entity, feel free to map that 'flavor' to the 'collection of actual display settings' (aka 'layout') you see fit"
layout variants by bundle are definitely needed, entity-specific variants ("layout for node 12") would be way cool :-). Field API, having display settings in $instance, is currently not very well wired for that, but if this plugs on a variant-enabled layout system, sounds within reach ? Maybe Panels allows that already ?
Fields and blocks
IMHO the meaning of "fields" and "blocks" will become self-evident to the user when they are displayed in a select list eg:
Blocks:
Site name
Search form
Main menu
Footer menu
Fields:
Page title
Page body
Author
tags
So both the admin (Drupalist) and content creator personas are covered. The only caveat is that it becomes more important for the site builder to name fields and blocks in a way that is logical and informative.
Re: What happens to entity view modes?
This is an awesome question. I'll be honest and say that I don't have 100% answer for this yet, BUT I can illustrate how things have progressed for me in the past, and we can maybe extrapolate from there.
I didn't even both using display modes until drupalcamp denver last year. And even then I would not have used them if Drupal Commerce hadn't piggy backed it's product display ajax magic on them. They're largely irrelevant to this work flow imo, BUT... I did start using them because of Drupal Commerce, and they have proven to be useful at times, however they are useful only in so far as having a set of defaults for fields.
What's that mean?
Panels currently requires me to reconfigure the output of my fields every new instance I place. This is tedious to a certain degree, but view_modes essentially do the same thing. So this is half a dozen of one 6 of another. Currently it only buys me the benefit of not doing it yet again. As I understand it, display suite can actually utilize the panels UI for view mode configuration of fields, and this is a compelling notion for me. In regard to the questions of variant support, node/%node is the greatest argument for supporting this that exists in core. There are others (taxonomy terms is a great argument too), but node type variants is the most obvious. I really think we should support what panels calls variants, and display suite's use of panels as I mentioned earlier seems like a really interesting way to do it. That being said, variants are needed outside of entities, but there might be some separation that could happen there as long as the system can be extended in that way. However that's an esoteric enough use case already that separating it might make grokking it even harder.
In short, what I'd rather do is provide any layout block that consumes context of a particular entity in place of view_modes. This would mean something like views could likely just pass a node through to a layout block designed to render nodes and you'd get rows of that layout block instead of rows of nodes displaying in a particular view_mode. In this way you can still do things like teasers, but it's potentially multi-column, you could load up the author and display their image and a link to their block, and, and, and... it becomes really robust really quickly.
In-page layouts and "library" layouts
Thanks for the reply, EclipseGc. Let me see if I understand...
What you're proposing is that we fully unify the "Manage Display" of fields within entity view modes with the Layouts work, by reformulating entity view modes as simply layouts that contain blocks (as is the definition of every layout), where most/all of the blocks just happen to be configured to display the desired field(s) with the desired field format settings. What we gain from this is that by Field API providing a block that can be configured to display fields, that block can then also be reused in the header or any other layout (similar to what Panels currently allows with content/field panes). Also, by entity view modes being full-fledged layouts, they can intermix non-field blocks in their display (as Display Suite currently allows).
That all sounds cool. What you're also saying is that these layouts can be used by Views (as row styles), and while you didn't mention it, this would also need to extend to node reference fields (the format setting of a node reference field would need to be able to reference which layout to use for displaying the referenced node).
What this sounds like to me then, is that from a administration IA standpoint, some layouts (e.g., "header") are accessed (in terms of administration) from the "Page manager", while other layouts (e.g., "article teaser" or even "2 column article teaser") aren't directly connected to any containing page layout, but are rather just out there in some kind of "library", available for referencing by Views, node reference fields, etc.
When I think about this as a programmer, that makes a lot of sense. Does it make sense from a UX standpoint?
[EDIT: looking over the beginning of this thread, this seems to match some of those sketches, which is probably a good sign.]
To clarify
On the topic of node/entity references, you wouldn't actually apply this in the way you mentioned. Those field types would still have display widgets... HOWEVER, if you wanted to you could load up the value of these fields as a full fledged context (of whatever type) and then rinse repeat from a display perspective with what we've already discussed. (This is what panels refers to as a "relationship")
In regard to a "library" of components. Yes that is definitely true, pre-existing layout blocks will be available in a library to reuse (I think the header, footer and sidebars probably qualify here too). What contexts are available will limit this list (if you have no node, there's no reason to see components that require one). Node pages could choose to utilize these components OR provide a one off solution for that particular node type. For the site builder who needs to organize and build re-usable components, he has that provided to him, and for the fly-by-night blogger who just needs to change the layout of his static pages... we support both, and we don't have to do any extra work to do this because the architecture already implies it. If we do the rest of the work appropriately, we should essentially get the behavior "for free". (for some value of free)
Hopefully that makes sense?
In short, what I'd rather do
A "display mode" is, essentially, a layout. It performs no other function, so isn't the assumption here that the block knows what fields to expect? If so, then you've just replaced display view modes with block view modes, difference is entirely semantic, as the layout is still dependent on the entity (and probably also its bundle).
Functionally, I think the implementation is probably the same, except you lose the ability to insert a block and chose its layout (e.g. display mode), because you have to choose the block layout directly. This means, if a user wants to insert contextual content, they would have to select the specific block layout version, and not simply insert the content object and then choose an appropriate display.
I think you can actually
I think you can actually refine this further. Any potential 'layout' is actually just a combination of 'chunks'. The bigger the layout, the more 'chunks' you have stacked up. If you define 4 chunks (full width region, left sidebar + content, right sidebar + content, 2 1/2 width areas) and give users the ability to stack chunks, you can create infinite layouts that have visual consistency. This way, you avoid the admin headache of creating and managing every possible permutation as a discrete 'layout'. You also give your designers a set of consistent markup to work against, since there really is only 6 possible divs defined for any layout, no matter how complex. This way you avoid the design free-for-all of a dynamic region creator (and all the ugly markup it requires), while still giving users what they want.
Actually, if you accept the
Actually, if you accept the need for nested layouts, you can do a single layout with 3 classes, something like...
<div class="container"><div class="row">
<div class="column">
..
</div>
<div class="column">
..
<div>
</div>
</div>
node fields in multiple regions complicates HTML5
"A challenge that pops up, however, not so much with node teaser listings, but within pages displaying one primary node, is that the content editor wants to put some of the node's fields somewhere different than the primary content area. And I don't mean just splitting the primary content area into columns, I mean into a full-fledged region, like the left sidebar, the same left sidebar that contains full-fledged blocks like search, navigation, and a View of "related links". And, according to HTML5, the
<
article> tag needs to be around all of the article."
My take on this is that if fields from a node are placed in two regions, then they should be treated as two different instances of a node and should therefore each should have its own set of
<
article> tags. Wouldn't that simplify things a great deal? I'm no HTML5 expert so please let us know if there is a drawback to this approach.
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.
Elements (not fields) and Blocks
The only limitation I see with view modes, is that the user is limited to fields available to a single content type. You can't add fields from related content types or blocks to your layout. With that said, I do like the concept of view modes as reusable elements.
I think we should allow the ability to add both fields and blocks to a layout. I see an element as a discrete piece of content: ie. node title, username, site logo, form submit button. A field, as a developer sees it, is just one type of element to any other user. I see Blocks (or components in the OP) as groups of elements and other nested blocks. Coming from a graphic design background, I liken this to Photoshop layers. A single layer is an element and a layer group is a block. You can then drag and drop groups of element in a block as you would a single element.
On that note, there is a consistent UI pattern that has been around for years. That of editing nested objects, groups or symbols. You can double-click a group (or click a contextual edit link) to edit its contents within its own context. This is usually accompanied by a breadcrumb that gives a visual indication of where you are in the hierarchy. This method could be employed to help unify the editing experience of different objects. I'm not sure what kind of memory implications this would have.
I see where Jay is coming from in regards to the 90% use case. But, it makes sense to me that the concepts remain consistent across the regions (including header and footer regions.) Then we limit access to regions that can be edited and the content (fields and blocks) available for placement, per role, as eclipseGC pointed out, to address that 90% use case as the default.
How about View-Modes in
How about View-Modes in Display-Suite @pixelwhip , you can add what you mentioned: Fields, Non-UI Fields, Related Entities & Taxonomy (using it's own ViewModes), Blocks
--
http://jmolivas.com/
@jmolivas
I was thinking of the core
I was thinking of the core "Manage Displays" admin page. I didn't realize Display Suite allows you to add all that extra info. That's good to know. Thanks!
All blocks
@effulgentsia
I would guess so. if I understand right, a block that displays an entity is part of the overall plan. Which fields get displayed and which formatter (I guess this will change to blocks too) to use will be part of that block's configuration? So, I guess, if this is right, the field UI we know today will be move to some sort of block configuration form.
@pixelwhip
Like you said if we keep everything consistent down the hierarchy of things being displayed (pages, list of entities, entities, fields and properties being displayed are all done through blocks), then there is no problem at all, you will be able to display any field (if there is an entity in the context) or any other block that is able to utilize the current context.
Some inspirations: orchardproject.net
I just got an invitation from Microsoft for the TechEd Europe 2012 and their site uses this CMS: http://docs.orchardproject.net/Documentation/Getting-around-the-dashboard
I never used it but on the first view some cool features like e.g. in content-types the container, html-widget looks similar to some ideas I have or I use already in views/panels but more on a workaround-base:
http://docs.orchardproject.net/Documentation/Creating-custom-content-types
I guess I should have a closer look next week when I am back home and have a test-pc with windows for that.
There are a lot similar used things compared to blocks here:
http://docs.orchardproject.net/Documentation/Customizing-the-default-theme
I came across this discussion
I came across this discussion while wondering around for an alternative for Panels, Context and stuff.
Very interesting indeed!
Three concerns here :
Everything should live in the code
User interface
Access permissions
Thanks again for this fantastic topic.
Worked on my own implementation of builder using paragraphs
Hello,
I worked on my own implementation of a builder (because needed since too much time). It's based on the paragraphs module. Basically it just hook the paragraphs module to display it another way (without the crappy tabledrag for multiple value).
See my post (with a demo) about it : https://www.drupal.org/node/2692051#comment-11311321
and a quick video