Was there a specific post that triggered this, or a more generalized impression?
> It really does help if we all share a similar language/point-of-reference.
I'd add a coda to that sentence. ", and the patience to teach that to others." I haven't always had that.
Naming conventions are important because consistency is important! Naming conventions are an intrinsic element of every discipline. They allow people to quickly communicate. They are shortcuts. They are drops of concentrated understanding.
Instead of telling someone to "take the number on top and divide it by the number on the bottom", you'd tell them to "divide the numerator by the denominator". Short, exactly to the point, no question for ambiguity. This becomes important when you're not face-to-face and conversing with someone who speaks a different language or is a beginner.
An example I run in to frequently is when a database table ends with "_V" (underscore followed by the letter vee). This tells me that I'm looking at a view, not a table. Most likely the view isn't physically loaded with data like a table. It also means that it's possible that the view may contain more or less fields than the table -- or tables! -- that it pulls from.
+1. I can definitely remember being new and intimidated on this forum--but I needed to learn some things, and FAST, and this forum helped me accomplish that.
Anyway, my point is: I agree that being patient, and helping others get accustomed to Tableau terminology, is an important virtue on this forum.
I heartily, wholeheartedly, and utterly agree.
The lack of a common language for talking about Tableau, what it is, what it does, and how it does it, is a tremendous barrier to achieving the various levels of competency required to use it effectively and well.
In a real sense Tableau the product, the tool that we use, is a manifestation of an analytical language that has a number of dialects-areas of effect that, when expressed, construct the visualizations.
The visual properties, placement, and configuration of the pills in shelves is the obvious example. Internalizing these and their effects is one of the first real hurdles, and there's no real verbal language for describing the analytical properties they express.
Table calculations are another situation. Although they're relatively simple on the surface, their roots go very deep, with sublteties, complexities, and consequences that are almost invisible to the untrained eye. Even teasing out the elements involved in the resolution of a specific Table Calc in a particular context can be a real chore, requiring highly developed sleuthing skills. Having a language to describe the structural elements involved, how the structures' contents affect the analytical operations, and the other parts and pieces (even here I'm struggling to find the right words), will be a huge step forward in illuminating what are now deep, dark secrets that don't give themselves up easily.
Interestingly, there is an existing materialised language that describes Tableau. It expresses the construction, content, and configuration of vizzes, dashboards, data sources, and Tableau's other parts. I refer, of course, to Tableau's workbook XML dialect. Of course, it's not really human legible, but it is structurally complete. Is it relevant to this discussion? Maybe; I'm not sure I see a mapping, although it feels like something's there.