Website Development Best Practices

On the development side there is a myriad of different types of “applications” that can be built out now-a-days; ranging from “simple” websites to more intricate software platforms. Oftentimes the need for best practices if overshadowed by the excitement of a new design (ie UI). The following are some high level standards we believe can serve as a guide for successfully addressing the development needs for any company. Our initial best practice foundation comes from approaching each project with a pragmatic mindset. That includes many more commonly thought of topic areas such as:

• WCAG & Accessibility Standards: Understanding why and what level of accessibility you are looking to achieve. Factoring that into any UX / UI concerns. Our developers specifically have a certification in accessibility standards when it comes to development.
• Documentation Standards: Internal code documentation / commenting as well as a library of external documentation (README, Swagger for API endpoints, etc.)
• CI / CD Pipeline Standards: We create dev, staging and production environments that have tests and linting written in order to allow for maximize efficiency of code pushes for the website / app.
• Page Speed Standards: We utilize Google Page Speed and Pingdom to optimize loading times to what is necessary in order for the site to rank well and provide a great UX / UI experience to the end user.
• Web Markup / W3C Standards: Going into any project our goal is to write as semantic as markup as possible. As a gauge to check against we run our code through a W3C validation checker, although that does not mean we aim to be 100% compliant.

Below we take the art of best practice setting in development to a discussion.

Tony: So, potentially a big question, hard to answer in a concise couple phrases, but describe website design development best practices that we follow or adhere to.  When I say best practices, what pops into your mind? 

Jake: I think of pragmatic.  And it’s approaching things in small incremental steps and making sure that we’re building up from a foundation of solid work and that we’re not just trying to pull a whole bunch of things together and then glue them at the very end and hope that things go well.  The idea is that we’re building a house, you start with a foundation, and then you start going and building the little living rooms, and then you can start the second floor. And so taking more of that approach is best. Also having good documentation and testing practices is really key.  

Tony: So, would you consider in that continuous deployment a method or strategy for that, working with the client on that, and then even going into things of like accessibility, what level of accessibility do you want, are you mandated by certain government entities or nonprofit statuses that you have to have a level 1, 2, 3, or 4, and again, then just general web markup practices too.  I know we do a lot of testing, but it really depends on what the client need is and we do, we want to have the best foundation, but then talk about those things that might tip it one way or the other, having a level 4 WCAG I guess affiliation could sacrifice UI, UX elements, could change the way you develop, and so what does that look like, what’s that tradeoff like? 

Jake: Yeah, so I think knowing those things is important at the start of a project, because it might change how design builds things out, and how we work with design, our designers have been trained on accessibility and so have a number of our frontend developers, and we always use a semantic HTML as we possibly can, so from that accessibility standpoint it’s not as much of an issue, it’s more as soon as you start adding in little popup windows and you get more into like dropdowns, and as soon as you start getting things animated within the site, that’s when accessibility becomes more and more of a concern.  At the end of the day, accessibility doesn’t just affect people that have disabilities, it’s somebody broke their arm. You know how many people break their arm in a year? A lot. They might have to have the new accessible things, too. So, it’s keeping those things in mind and knowing up front what that means, but going to your CICD and kind of continuous integration and deployment, we implement that for every single one of our web applications, it’s crucial. We actually don’t even deploy to production directly, everything runs through our pipelines to make sure that it’s formatted properly, that it passes our tests, we do static security analysis to make sure that we don’t have any lost vulnerabilities that certain scanners are able to pick up, and then assuming all that goes well, then we deploy to either staging, or production, or QA environment ,depending on where we’re at.