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.
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).
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.
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 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)...
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.
To make more sense of this, consider these two site builder scenario’s :
“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
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
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?
- 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?