Sitecore Tip #4: Use Audience-Focused User-Friendly Consistent Field Names
While this is sort of a very intuitive practice, and likely all developers would confirm they follow it, in reality – many do not. Here are some of the golden rules I follow:
- Use spaces in complex field names (no underscores! I don’t care, if it’s easier to bind to object properties – your audience is Content Editors, not developers)
- Use field names intuitive to a non-technical person
- Use client’s terminology
- Give same names to fields serving the same purpose
Since the first point is self-explanatory, I will focus on the last three. For example, let’s use what is probably the most common template that gets created in Sitecore – an Article. Let’s also use a very simple article, which only consists of a Title (title of the article), Summary (a short paragraph summarizing the article), and Content (the article content).
Although there seems to be no room for confusion at this point, many developers still seem to mess this up. I have personally seen many Article-type templates called Pages and Documents. Title field varies from Title, to Headline, Heading, and Name; Content can be called be Text or Body, and the Summary has been seen as Abstract, Introduction, Quick Description, and even Blurb! Not only these fields tend to get different nicknames, they have been seen to vary from one template to template in the same solution. For instance, a News Article would have a Title, and a blog post – Headline, which begs a question – what is the difference? As a Content Editor, I would find it confusing that fields with the same purpose carry different names.
At this point many developers can argue that using Headline is better than using Title for titles in news article templates, and others would claim that Heading is the only proper name in those cases. The truth is that they may all be right. Wait, what? So which one should be used? All these names may be correct in different situations, and the client should be the Supreme Judge.
This is exactly why it is a good idea to bring architects and developers into client meetings, so they can learn the client’s language. Even though, as a developer, it would make sense to name the field containing content – Text (which makes complete sense, right?), the client constantly refers to it a “Copy”, thus, it should reflect that client’s language and be called Copy.
As developers, building in Sitecore for years, we tend to get carried away with our own naming conventions, which may make sense to us, however, be confusing to our clients (plus training clients on what an article summary is much easier than decoding the abstract meaning of an Abstract field.)
You must log in to post a comment.