Simple things that matter

While most of the talks focus on complexity and new tools and technologies, I'd like to go against the stream and focus on simple things.

There is a lot of simple tools in Drupal which are generally underused but which could contribute to user-friendliness and maintainabilty of the website. To name a few: field descriptions, field type and widget, views and rules tags, features groups, views descriptions and comments. Then go form elements and settings, CKEditor or WYSIWYG styles, and this list can be continued.
Technically, everyone knows about these. But still they are underused. What drives developer or sitebuilder? In first place, the need to close a ticket - which is 99% about the functionality, like "create field", "create content type", "build a view". No one would really care about details, as far as the solution is functional. In second place, acquiring new skills, because skills make the value of developer. So, instead of spending his time on writing field descriptions, which is technically the simplest thing, he would prefer save time and plunge into more challenging tasks like writing hooks implementation or mastering gulp.js.

But if we take the product as a whole and look into some middle-distance perspective, we'll see the importance of these simple things. Often field names don't provide exhaustive information. Eg, "GLobal IDEntifier Number (GLIDE)" - this may make sense to some people in the field but not to others. Are there any limitations on values, eg, if it's a number? During its lifecycle, the site will go through the hands of content managers, developers, testers, some of them will be completely new to the development, others - to the domain, and providing comprehensive help is essential for avoiding hours of frustration. Let's take another example: it's not uncommon to have ~50 views on a site. And determining which view produces certain page may be daunting (contextual links should work, but in 10% of cases they won't help). Properly tagged views may reduce the number of views per tag to ~5 - 10, which makes drilling down to the proper view several times faster. And everyone run into the situation when a view doesn't behave as expected, and after some hard time you find some view hook implementation. Writing this down in views comments may save a lot of effort in the future.

These examples are numerous, but for the description of my proposal I need to sum up with the message I'd like to convey:
"Think about people who will work with your site. Think forward. Use simple tools."