Add detailed Views naming and building conventions to debut

General Guidelines for Creating Views

These recommendations came from preparation for a talk at the 2010 Pacific Northwest Drupal Summit entitled "Build Views that will please your OCD co-workers". Thanks for the feedback. And yes, the OCD part applies to me.

Creating the View

• Try to name your view as concisely as possible. For example a view that will create mostly event displays should be named "events".
• Make sure to keep the view name lowercase. Otherwise uppercase characters will be added to the classes to your views' displays.
• Give the view a description. If you work in a team, it might be useful to indicate the team member who is responsible for the view.
• Tags are useful when you know you are going to create multiple views with a similar purpose. For example, a blog may require a node view and a term view. Whenever you have two or more views dedicated to the same section or functionality, use a tag to link them together.

Creating displays

Give a distinctive name for each display. For example, the following display names for each display might be necessary for an event section:

• Landing: the landing page of the event section
• Featured Front: Either a block or a content pane (for a panel) to be displayed on the front page
• Upcoming Sidebar: a block of with a list of upcoming events
• Archives: page with event date argument
• Archives Sidebar: block with summary date argument

Some have made the argument that each display name should also include the display type. For example, "Landing" in the example above would be "Landing Page", and "Upcoming Sidebar" would be "Upcoming Sidebar Block". Personally I find this somewhat redundant. Properly naming a display by it's function should make this obvious.

Override Only Settings

Some settings in a display's basic settings, due to their nature, are better being always overridden on each display. They are:

• Title
• Use Pager
• Items to Display
• More Link

Style

• We recommend using Semantic Views for the vast majority of view displays since it can dramatically reduces the amount of divs and replaces them with meaningful markup.
• Grid View is to be avoided since it is generally a semantically incorrect use of tables. In the vast majority of scenarios, the grid view style can be achieved by creating floats (for elements with equal heights) or "inline block floats" using the display: inline-block CSS property (for elements with varying heights).
• When creating a node display, it still advantageous to select Semantic Views as the style, as this allows us to remove the extra unnecessary div that surrounds each node.

Row style

If you are using Semantic Fields row style the context is what will determine the appropriate choice for surrounding HTML element. Generally, it is best to utilize the heading elements (h1 to h6) as much as possible to maximize SEO performance. For certain fields, like single image fields, it might be appropriate to not surround the field with any HTML element.

Working with Semantic Views

When using Semantic Views as the display style, a user can specify the wrapper element of each views row (or omit it completely). The most common choices will either be a div or a li. Regardless of your choice, we recommend the following class names: views-row views-row-# name-of-content-type. The reason for specifying a views-row class is for consistency across displays. Some types of displays don't allow Semantic Views row style, so adding a views-row class give you the ability to globally style displays, regardless if were using Semantic Views or not on some of them.

As for the Semantic Fields row style, the right element and class depend greatly on what you are displaying. For example, an image may not require any wrapper element. Generally, it is important to maximize the use of heading elements (h1-h6) for increased SEO perfomance. If your theme uses the h1 element for page titles, and h2 for block titles, then you typically would want the first fields in a row to be h2 for page displays and h3 for block displays, and so on for following fields.

CSS Setting

A set of three CSS classes is recommended for each display. For example the events landing page mentioned above should have the following CSS setting: "events-displays events-pages events-landing". The benefit of each CSS class are:

• events-displays: allows the targeting of all displays in the view.
• events-pages: allows the selection of all displays of a certain type in the view.
• events-landing: allows the selection of a specific display in the view.

There is one exception to this recommendation for blocks and content panes, depending on your theme's requirements. This is because they are already surrounded by a wrapper with either a unique ID (in the case of blocks with good starter themes) or classes (as is the case for panels where you can specify either an ID or classes)

Block and content panes

• Avoid using blocks for panels. This keeps your block administrative more manageable. Furthermore, content panes allow you to override many display settings directly from the panels interface. Content pane displays can be created by installing the ctools module.
• Always give blocks and content panes an administrative title. For example, for the display "Upcoming Sidebar", an admin title of "Events - Upcoming Sidebar" would be appropriate. We start the admin title of the block or pane with the name of the view, simply because all related blocks or panes with this view on the panels or block admin interface. - 

Rewriting fields

One of the most powerful features of Views is the ability to rewrite the output of the fields. Together with the ability to exclude fields from display, we can combine several fields together.

For example, we may want to combine a user name and post date fields together so they are presented on one line: ie. Posted by Jake on November 3, 2010

Here are some recommendations when rewriting fields:

• For the fields you want to combine, make sure that you always choose the following options: exclude them from display, hide fields if empty.
• Add a global text field, and make sure it is below the two fields you want to combine.
• Rewrite the global text field and add the placeholders for your fields. In the example above, we would add [name] [created]. At this point, the output would be Jake November 3, 2010.
• Go back and edit the title field and rewrite it to Posted by [name].
• Go back and edit the post date field and rewrite it to on [created].

Be careful of how you rewrite fields. For username and post date in the example above, we can be fairly confident that those will never by empty, but that is not the case with all fields. For example, imagine that the post date was some optional field. The reason I chose to add the word "on" in the post date fields is that if the date field was left empty, we could end up with this: Posted by Jake on: an incomplete sentence that looks silly.

Caching

Just prior or at launch, make sure to enable caching to improve performance on your site. It is highly recommended that you use the Cache Actions Module in conjunction with caching your views. Cache Actions allows you to clear a views cache with the Rules module. This means that whenever a user creates a event node, we could clear the events view cache to update the displays immediately. This is particularly useful when a third party will be creating the content, especially if they don't understand caching.

This looks good. A few questions for @rhache: should the view displays be all lower case or have init caps? It is worth noting that block displays should have the administrative description field filled out with a meaningful & concise description.

Missing from the above is your recommendation that when using the re-write field option with a field style display, you recommended using the global: custom text field and suppressing the display of the fields to be rewritten.

I'd also like to see something about the recommended naming convention for feed displays, specifically the url path.

Hi Gregory,

In my opinion, the view display names should have an initial capital, be somewhat human readable but as concise as possible.

I'll add the bit about rewriting fields soon, I had forgotten about that.

As for feed displays, I usually simply add /feed at the end of the url of the page display it's related to -- ie if I have page display with a "blog" path, the main blog feed would be "blog/feed" (I know feeds are not always tied to a page, but usually yes in my experience). However, I'm not a big RSS expert and would appreciate other opinions. I'd also like to know if for feeds if it's recommended to have a particular "items to display" value.

Thanks,
Rene

Added some bits about Semantic Views and recommendations for rewriting fields.

Rene