Views Quality Checklist
Much has been written on how to use the Drupal Views module effectively, but less on how to use it like a perfectionist professional. I started the following checklist for my team to level up everyone's pre- ticket review quality, but it can be useful for any Views builders.
Getting Started
On every site, run drush vd to turn the Views settings to the advanced mode.
Naming
Name your new View as a container for the displays it may someday contain, not just the one you're making now. (e.g. "News" not "Frontpage News Pane").
For complex rewritten fields, contextual filters, relationships etc., use an administrative title in the 'More' section of the item's configuration. Don't make others click on the settings to understand what you built.
Displays
Give each Views display a descriptive name (e.g., not just 'page' or 'pane').
When using Panels, the best type of Views display is generally Panel pane. Never use a Block display for a View to be placed in a Panel.
Fields
Don't complicate Views with rewritten fields where style settings could suffice to make fields inline or within the same table column.
If using a Node ID field, set the number format to not include a comma.
If a View is the main listing for a type of content, shows fields not full content, and does not include links to individual entities (i.e., the individual entities are not easily accessed on the site), include an edit link field for editors.
Use a Display Suite view mode rather than fields when the display mode could be reused in the future.
Pagers and Read Mores
Most Views displays will require either a pager or a "Read More" link that points to the display with the pager.
For Views displays that are a main listing, include a pager. The number of items to display and pager style (usually full) should be consistent throughout the site as much as possible.
For Views displays that are not the main listing, configure a more link. Set the link to always display and use consistent text throughout the site (e.g., "Read More"). You may need to configure the Link display path in Advanced Settings.
If the View has a "Read More" link, avoid using "Read More" links in the individual listed items or ensure the text and/or styling is clear differentiated.
Exposed Filters
Include "No Results Behavior" text for Views that may have no results, including all Views with exposed filters. Make the language consistent, concise, and professional because it is unlikely to be improved in the future.
Change the default Filter Identifier strings for Exposed Filters (in the 'More' settings) to make more readable query strings.
Unless deep-linking is desired, set Views to "Use AJAX" if they use a pager or Exposed Filter.
In Exposed Form Settings, set the button text nicely. Set the form to autosubmit and/or include a reset button where useful.
Table Style
When using a table display, make columns sortable where possible.
Don't use redundant column headers (labels). For example an 'Edit' link field does not need a column header displaying 'Edit'.
Performance
Turn on caching.
Admin Views
Set access to an administration View based on Permission not Role. Use a permission that makes sense. If none make sense for your use case, implement hook_permission.
Place administration Views pages in a sensible place in the menu. For example, a specific content admin page could be a local menu task under admin/content/node.
For content-based administration Views, include a header where useful with links such as "+ Add new foo".
QA
Test your Views displays while pretending to be a typical user of the website. If you modified one display, check all the displays because errors between Master and Override settings are common.
Use Devel Generate locally to have plenty of content to test features of your View such as paging.