For all of Cantilever’s history, we have maintained a clear and specific style for all of our website builds (BEM syntax, vanilla JS, ITCSS, things like that). We would train new people in this style as they worked on our stuff. Over time, we have found that while effective, this style is just very difficult to communicate. In fact, any web development style is hard to communicate, particularly in a remote team.

As of Fall 2020, we have decided that instead of enforcing a strict stylistic approach to every website build, we instead maintain general quality standards. In other words, we measure output, not input. This will allow different talented developers to come in and be effective sooner. It will also allow the whole team to witness different approaches we might not have otherwise permitted to be tried.

The downside, of course, is that we have to very picky about the work we consider "good enough." Our standards are as high as ever when it comes to user experience and Digital Hospitality. We must always provide unparalleled quality and value to users.

This change is in recognition that the web itself has changed. More valid approaches are possible in 2020 than in 2011 when we started. So long as developers adhere to our overall principles and deliver an outstanding user experience, we can be satisfied that the work is Cantilever-y.

To inform design and development and ensure that QA is done in regard to a common core Cantilever standard of quality, we will maintain this document to outline what we and our clients expect of a Cantilever product.

Different projects will have different requirements in various areas. An internal app, for instance, must be incredibly fast, but doesn’t require any SEO attention. A blog, meanwhile, doesn’t need much visual polish, but SEO is imperative. The documentation for each project should outline our and the client’s expectations within each category.

Requirements Matrix

Design Fidelity

For projects with design comps, we always expect that any final comps are obeyed. In all projects there are grey areas, since comps cannot be responsive, and cannot possibly display all application states, so frontend devs are expected to use good judgment in extending the design team’s intent throughout the full site experience. The exceptions are when:

Other than that, please pay very close attention to detail in frontend work. Comparing the comp to your frontend at the same screen size, any differences should stem from one of the above reasons.

Change Management

Changes to our standards should be done by consensus of the group.

Any individual can recommend changes to the group. They should do so by writing a message in the Development project in Basecamp with the requested change. If nobody says "No" and at least one person says "Yes", the change is approved. Everyone who does development for us needs to meet the standards, so every developer is invested in thinking about and reviewing changes when they happen. If anyone says "No", discussion should continue until they either say "Yes", or we reach an impasse. If we reach an impasse, the lead artisans (@Andrew Heins and @Brian Kuperman) should make the final decision, taking into account all factors and opinions stated.

Different departments have slightly different focuses (for instance, the support department is more affected by security policy). Any change should be especially validated by the people who will be affected the most. Similarly, different developers have different specialities. Domain experts should have more of a say in the discussion on any particular topic, but that should not exclude newbies from being heard and respected.

As a business, we often don’t get to make decisions the way we would if profit were not a factor. Please keep in mind that our choices must be practical and pragmatic relative to the way we work with clients.

Please note that these standards are not going to match any individual team member’s own preferences 100%. They are about having a common shared understanding, not necessarily doing things exactly the way any one person prefers. Principally, this is not "the way Ty likes things done". This must be based on the shared logic of the whole team in regards to how we can do our work in a way that exceeds our user experience standards while satisfying business needs.