• Services
    • Headless Ecommerce Development
    • Ecommerce UI/UX Design
    • Agency Support Services
    • Platforms
    • Shopify Plus
    • BigCommerce
    • Craft CMS
    • Shogun Frontend
    • ButterCMS
  • Case Studies
  • Blog
  • About
  • Contact
  • Company
The Importance of Language Standards in an Agency  |  Read time 5 Minutes

The Importance of Language Standards in an Agency

July 05, 2019 |  Read time 5 Minutes

By Electric Enjin
language standards for the agencies

An agency is a team just like any other; it is an amalgamation of people working together to achieve a common goal. Whether that goal is to reach home plate, put out a fire, or build a website, communication is paramount to success. Poor communication in a development team means spending more time and energy rectifying otherwise preventable mistakes. 

A team has to be able to communicate effectively and quickly, with no discrepancy between what a team member thinks something is supposed to mean and what it actually means. This is why it is important to establish a shared language between team members, so that there cannot be any misunderstanding of what is asked of them. 

The word “unit,” for instance, can be defined as “an individual object regarded as single and complete but which can also form an individual component of a larger or more complex whole.” Some synonyms for “unit” are; component, section, element, feature, subdivision, item, segment, and  module. Terminology like this can be easily misconstrued, especially when other development terms such as section, element and module are considered comparable synonyms to the term in question.  

One developer, for instance, may hold the perception of a unit as a small part that goes into creating a larger entity. They may also hold that this larger entity may be referred to as a module. In the same respect, another developer may hold the exact inverse of those notions as truth. This creates a costly conundrum – one that is easily avoided by establishing a common language.  

How do we begin to create a common language between team members then?

A list of terms and the rules that are associated with them to describe digital objects is a beginning, but that simply does not constitute a language. Language is based on a common perception of a term.  A language is born when the meaning of specific terms is uniform throughout an agency, and each team member has a clear distinction in their mind of what each term denotes and how to properly use the terminology.

In English there is no real substitute for the word skyscraper. When we hear this term we know what it means; a skyscraper is a very tall building of many stories. We would never call a skyscraper a shed, a house, or even a giant block of concrete, metal and glass. The term skyscraper comes with its own connotations – it is a building that “scrapes the sky”. The term even has strong associations. A skyscraper is found in a city, not a village, field, town or hamlet. Just as a footer is found at the bottom of a page, much like feet are located at the bottom of the body. The terms header and footer are excellent element names because they describe to some extent their position and purpose in a concise manner. It is best to aim for semantic names that are as easy to interpret as possible. 

Ideally, the language shared between agency team members should be just as obvious and have just as strong connotations as the skyscraper example above. This means creating terms for digital objects that are as semantic and descriptive as they sensibly can be. Although it is very descriptive to refer to a skyscraper as a giant block of concrete, metal and glass, it is an overly long and convoluted name for something that already does a good job of describing itself. Rather than assigning an html <section> the class “section-1” or “section-A,” it would be far more relevant and descriptive to incorporate the content housed in that section in its name. If the section in question contained a list of products available for purchase, for instance, it would make sense to assign that <section> the class of “products” or “products-list”, rather than a generic and non semantic class name that gives no indication of what is happening inside of that section.  

You could ramp up your naming even further by assigning a section an even more specific name given its location on the page. “productsListTop” for example or “productsListHome” describes both the location and content of the section in question. If there are multiple sections housing similar content, clothing for example, the class “productsMensShoes” or even “productsMensShoesTop” might be the best way to convey what that section is about. There will be times in an agency setting that people who have very little exposure to web development need to reference a part of a website. The more specific you are, the easier it will be to communicate between members of your team and beyond.

A good relationship between the design and development departments is very important to the success of an agency. It is wholly necessary that designers and developers are referencing the same items when they collaborate. If a semantic convention is used in naming and a shared language is established agency wide, it will be easy to run back and forth between multiple design and development iterations without having anything lost in translation. Quicker turnaround time on design and development iterations means producing product in a more efficient manner. 

Not only do semantic names matter in aiding overall understanding throughout an agency team, but there must also be a standard for writing these names. This is called a naming convention. Generally there are two ways in which we can name objects within a web page: using dash notation (this-is-a-name) and camel case (thisIsAName). Depending on your team’s situation and thought process, one convention may be preferable to use over another. 

This brings me to my final point, which is establishing good communication between team members by – communicating! Get together as a team to discuss the collective perception of your terminology; what you like, what you don’t, what needs to change, what should stay the same and why. Not only will this lead to a language shared between team members based off of a common perception, but it will give each individual insight into how the other members of their team think. 

This approach should not be limited to just web development but should be used in every facet of an agency. A common perception of brand, design, and development patterns is essential to a well functioning agency team that can communicate and work effectively and efficiently.    

The Importance of Language Standards in an Agency
Electric Enjin
  • Craft CMS Partner
  • Shogun
  • ButterCMS
  • Shopify Partners
  • Zendesk Partner
  • bigcommerce partner

Electric
Enjin

  • Home
  • Work
  • Company
  • Careers
  • Blog
  • Contact
  • Rss
  • Blog Archive
  • Work Archive
  • Sitemap

Our
Services

  • Headless Ecommerce Development
  • Ecommerce UI/UX Design
  • Shopify Plus
  • BigCommerce
  • Craft CMS
  • Shogun Frontend
  • ButterCMS
  • Agency Support Services

CMS
Guides

  • Shopify vs Magento: The best ecommerce platform for your business
  • Shopify vs Shopify Plus: Is the price tag worth it for your ecommerce business?
  • Craft CMS vs WordPress: Which is the best CMS? 2023 Edition
  • Craft Commerce vs Woocommerce
  • Craft CMS vs WordPress: SEO Matchup
  • Craft Commerce, Shopify & BigCommerce Platform Comparison

Let's
connect

  • 203-939-9344
  • [email protected]
  • Electric Enjin
    20 N Main St
    4th Floor
    Norwalk, CT 06854

Ecommerce tips & insights
straight to your inbox.

© Electric Enjin LLC 2023.
Electric Enjin is a certified Minority Business Enterprise.

Privacy Policy

×

Let's Talk

To get started, we just need a little information.

Noel Lopez, Client Success Manager

Chris Ching, Founder


What to expect

  1. Chris will reach out to schedule a free 30 minute consultation.
  2. We'll discuss your goals, requirements, timing, and other details.
  3. Afterwards, you'll receive a tailored proposal.
  4. We get to work.
×

Give us your email (so we know you’re not a bot) to access the case study.