Publishing Real Content

A hybrid "published content" system with realtime data makes for a better experience for humans, and a more visible site for search engines.

Unlike most CMSes that are fully compiled and delivered at "runtime", our CMS is a hybrid content publishing system. Published content is easier to manage, easier for search engines to understand, and easier to upgrade down the road because pages are real pages that contain their actual content. 

Custom publishing for custom needs

Each site we build has a custom level of content publishing, and high-profile campaigns or high-usage pages are published to a greater extent as to keep the servers running smoothly and nobody needs to wait for their content.

Actual files, actual file structure

We do something novel here at Byte. We use actual files with real content right (gasp) on the page. That's something that the industry has moved away from for a variety of reasons, and we're bringing it back.

Why? Because real files always work, today, when the database goes down, and in the future when you want to upgrade, and in between when another developer needs to get in and make a page change without using the CMS. 

Since we've learned over the years that nobody can really predict how technology will change, the closer to semantic or "real" the content is, the easier it'll be to import into something new.

As a studio, we religiously avoid overcomplication because we've been around longer than any web developer you know. We've seen so much change, and we're still supporting 15-year-old sites. And overcomplication is the best way to make everyone's job harder.

A "headless" CMS?

One of the best byproducts of our process here is that if you choose to not use ByteCMS, want to use another CMS concurrently, or want to upgrade to a new version of ByteCMS, it's simple. Unlike most content management systems, the site will continue to work flawlessly. 

It's not a "headless" CMS in that it publishes everything, we're specific about the parts we full-publish and the parts that are computed every view. It's headless that you can wipe the management part and drop in a new one, or run more than one CMS concurrently. We've run other CMSes as parts of production sites as necessary.

A studio-wide philosophy on seven levels of usage

With our years of web design experience, we have a specific process we code our sites within. We hand-code our websites without using large front-end frameworks because it makes a far more standardized, "semantic" (codes with clear meaning) web site. We create real pages in real directories that follows the content strategy, connect to straightforward data tables, and publish and denormalize data when necessary. Essentially, we code a website that's easy for at least six groups of users:

  • Website visitor (human)
  • Website visitor (bot, including search engines)
  • Social media or other sharing tools (bot parser)
  • Website content manager (human with special powers)
  • Website coder (human with nerd powers)
  • Database administrator and designer (human with nerd powers)
  • Future website coder (4th dimensional human, maybe works at Byte)

Each one of the group has its own needs, and each has its own set of codes or processes to make things easier. The more semantic, "real" and standards-based we are, the more we make every group's job easier.

The key for every single user type is that they have to feel comfortable in the world they're working within. The coder needs to see commented, semantic and well-tabbed code, the social media person needs to have the right tags to make what's going on clear to all who see the post, the database admin needs to see pure data in the tables, and the content manager needs to have a history of the files and a sense of how they're being seen on the outside.