On Language and Usability and Panels 2

It is well documented/recognized that Drupal is really not very good at picking and sticking with a nomenclature that makes sense to the un-indoctrinated. The recent user testing at UMN made that pretty clear.

As the person on the team who is often working on the configuration of a website and running into the language in the GUI and then explaining the newly built site to the client it is often not until I do the latter that I realize how convoluted some of words used in Drupal are.

Recently I have been working with Panels 2 (Beta 3) and a few weeks ago wrote about my first few days wrangling with it. First let me say that the module is awesome, neigh, REVOLUTIONARY. I love it. I just hate some of the words used in it. I’m specifically having trouble wrapping my head around “context”, and most importantly “view.” While “argument” is familiar from views, the new “context” tab interface in Panels2 makes using arguments a little more confusing than in Panels. “View” when it is used on the main panels page at admin/panels is by far the most confusing.

Those of have been using Panels 2 know that you can add a view to your panel from the list of “contributed module panes” OR you can first add a view to the panels system, rename it, give it a new title, make it “context” or “argument” aware and then add this new derivative view as a pane to your panel. The latter is what you should do, but especially if you are used to earlier versions of panels, you might do the former and wonder where controls for view type (block, page, embed) and number of posts, etc… went. Well, they are all in the configuration of views as panes within panels.

My suggestion would be to change the nomenclature here. When you are in the panels system, it may make sense to create a “view pane” for use in your panels. This one simple change, at least to me, would make the interface significantly clearer. It is unclear to me how much of this will change when Views2 gets released, but it is something to keep an eye on.

The Context Tab

I wish that I had a similarly simple suggestion to what to do about the term “context”. “Context” seems to suggest something similar to an argument, too similar if you ask me. I feel like I don’t understand “contexts” well enough to make a really informed suggestion, but if I don’t understand it, I fear that it is completely out of reach for the average user.

One problem I see with the “Context” tab is that there are three things in the context tab: the context, the argument and the relationships. I think having the “context” function in the “context” tab along with other functions causes confusion. I think the solution here may be to rename the “context” function so it is more clear. Some of the help text needs improvement. This sentence makes my head spin “Relationships are contexts that are created from already existing contexts;” and while that help text goes on to explain a bit more about what you can do with relationships, the help text for “contexts” does not really explain why you would use a context, or what you would accomplish by using one.

More on Usability

The first page you hit when you start working with panels is admin/panels and the first thing you need to do is scroll all the way down the page to get to the links to create any kind of panel. It would be more useful to put the explanatory text that appears at the top of admin/panels inline with the actual links to create different kinds of panels, in the way that explanatory text is displayed on the node/add page. Further more, the general panels text should be “hide-able” I only need to read it a few times (the first 3 paragraphs) or it could be moved into a help page “about panels”.

When you are on the “content” tab of your panel there are a number of opportunities to get confused or frustrated.

  • Click on the add pane button and you get a pop-up add content widget. This box is not resizeable, and if you have many views, the one you want is probably below the fold, requiring you to scroll down almost every time you want to add a pane.
  • Views are arranged by the display title rather than the view name. View titles are not necessarily unique, while view names are, there is no way to discover the actual view name and thus there is a high likelihood that you could add the wrong view because you have 2 that have the same title. When you mouse over the view the view description is displayed, which could be helpful if you have written good descriptions. Better would be to display views by view name, and on mouse over show “view title: view description”
  • Once you have added a bunch of views to your panel, there is no way to determine which views these actually are since they are only displayed by the original View Title and the custom view title you may have added. Again, views should be identified by their unique identifier: the view name.
  • The user should be able to go directly to editing the view FROM the panel content display, this would streamline the process of tweaking your panel view panes.

Titles and SEO

Page titles are important for search engine findability. Panels allows you to set a panel title which is displayed in the browser title bar, and also at the top of the panel where it is, by default, aligned to the far left of the panel. If you are using the drupal block regions, this generally works out, as long as you want a title to show up at the top of your content area, however if you are using a panel sidebar, then the panel title will align left above the panel sidebar. This does not seem to be desirable in my experience. I am not sure that there is any programatic way to “fix” this, and I am sure it could be fixed by theming/css. What I would like to see is a “display title on page” and “display title in browser” radio button/check box. I’m told that this may be functionality coming in the Page Title module.

While I’ve been critical of some usability issues in this post, the functionality that panels offers is bar none. I love it. I just want to see it accessible to the widest audience.