4 Replies Latest reply on Dec 20, 2013 10:11 AM by Chris Gerrard

    Naming Conventions.

    Shawn Wallwork

      It is becoming more and more clear to me that a name matters. This is something Joe Mako and Jonathan Drummey tried to point out to me on more than one occasion. But being hard-headed my thought was 'call it whatever' we know what you're talking about. As has been the case many times over the past two years, Joe and Jonathan have proven me wrong.

       

      Reading through the answers from many new helpers has convinced me a shared/common naming convention is both necessary and helpful. Here's a good starting place:

       

      Tableau's Naming Conventions

       

      It really does help if we all share a similar language/point-of-reference.

       

      Cheers,

       

      Shawn

        • 1. Re: Naming Conventions.
          Jonathan Drummey

          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.

           

          Jonathan

          • 2. Re: Naming Conventions.
            Toby Erkson

            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.

            • 3. Re: Naming Conventions.
              Matt Lutton

              +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. 

              • 4. Re: Naming Conventions.
                Chris Gerrard

                +n

                 

                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.