Process process process

Editor's Notes

1. Front End Dev for Zenman for over 3 years. We do web design, development, branding and print, pretty much a full service ad agency. You can follow me on twitter if you're into really bad development jokes. And gifs.
2. Going to be talking to you about specific tools that we use to help us manage and iterate on process, going to go over some of the steps we go through when setting up a site, processes within our starter Wordpress Template, and finally give you some insight into our Testing and launching procedures. Having processes in place is key to maintaining your sanity if your a freelancer, and the sanity of your team members if you work at an agency. Processes like the ones I’m going to talk to you about today have helped our team work better and more efficiently, leaving us with more time to do cool stuff. So the first step in all of that…is to just get started.
3. Most important thing is to just start. Put something in place. No process is ever perfect One complaint I hear; bad time to implement new process. Truth is there is never a “good time” to start. Pretty much just have to do it.
4. First step is to identify what you're trying to solve Zenman needed; a development process that would standardize practices. (each dev had their own class naming structure, methodologies, works fine when you're alone, but makes working in teams a nightmare) Really try to have a solid vision for the perfect end goal. Figure out exactly how you want something to work, and then work towards that. Once identified you start thinking through how best to solve those issues, and what tools can assist you in doing so.
5. Think of tools that will work in conjunction with your process. Tools need to be interchangeable. A better solution comes around, your process doesn't need to change for the tool.
6. Projects and communications need a place to live. Features; to-do lists, documents, file share, discussion. We have really rigid processes for things like initial site setups, testing, all the way up to site launches.
7. This is our initial development checklist. At a high level we have to-dos for things like plugin installs, basic security features we add to our sites, setting up analytics and a bunch of other basic site setup tasks. These steps remain regardless of wether or not we choose to use basecamp. Basecamp however has made it easier for us to collaborate and iterate on this process
8. How many folks have gone through agile training, or at least have an idea what agile is? There are a ridiculous amount of agile tools. Pivotal works well with our process. Gives us very granular view of each project and it's progress. Most agile tools center around stories, and the acceptance of those stories by a Product Owner.
9. This is what a brand new tracker instance looks like for us. You’ll notice lots of the same to-dos from BC as stories Helps emphasize that the process doesn’t change based on the tool. Tracker is used internally for developers and designers @ Zenman Lets us see who is working on what at any given time, for any project.
10. Our clients need to manage their content, and most times require a blog. Wordpress is obviously built for this, and isn’t going anywhere. We also do software development, and will only recommend WP if it’s the right solution for the client, but generally it is.
11. I didn’t realize this until I was researching for this talk. That’s over 163 million websites…
12. We like to start fresh. If you google Wordpress starter theme you’ll get a TON of results. I’m sure you’ve all heard of themes like _s, bones, starkers etc. I’ve used a couple of these myself, and Zenman used to use Starkers. All of them came with some bells and whistles that we didn’t necessarily need. So we built our own.
13. An objective we had at Zenman was to maintain code quality across projects, regardless of the developer. BEM takes a sort of Object Oriented approach to class naming to ensure that our class names are descriptive enough to establish the purpose of that module. It takes a little getting used to, but once you get the hang of it it makes working in teams easier, and helps to keep things quite organized. Harry Roberts wrote a great article that explains the methodology behind this.
14. Another handy feature in Zemplate, is our utilization of the Atomic Design structure. Stephen Hay (does a lot of speaking about open web standards, and accessibility) said it best “We’re not designing pages, we’re designing systems of components.” Brad frost took that quote and turned it into a methodology for creating design systems. This is our interpretation of that in relation to our SASS files.
15. We’ll start with the largest first. Stars, being the largest body in a solar system are very high level, overarching styles which everything else rotates around. Things like frameworks, in our case foundation ( the grid specifically ). Variables, extends, and mixins live here as well. Generally things that don’t actually get compiled and output to the CSS File, rather they are tools to be utilized throughout the rest of your files.
16. Moving down in size we have planets. This is where the real structure of the site resides. Global styling for basic elements reside in the Base folder. Essentially just chopped up normalize. This is where we set the defaults for things like heading sizes, list styles, forms etc. The layouts folder, shockingly, houses layout declarations for each of your modules. We have a generic naming structure for these files as you can see with the _torso_with_sidebar.scss. For an item that appears on a page, for example a CTA section we call this _page_cta_layout.scss or something similar. Our file names are intended to describe the module associated with that file for easy collaboration and troubleshooting. In some cases it makes sense for us to reuse the layout/functionality of a module, which is why we separate layout rules within these files. Makes it super modular for us, and quite easy to grab files with associated filenames for use in other projects.
17. This is one of the areas we’ve been iterating on a bit. We’re currently working on a different structure within this folder for a few reasons. But for now we have overall component styles housed within this folder. You’ll notice we have some pretty large modules within here such as _head.scss and _foot.scss. Since these things are generally specific to a project due to the styling, we keep these separated out. Since modules are rarely ever styled the same, we tend to not need this part to translate to another project. The same file naming structure applies when we add an item to the page. Difference here would be _page_cta_styles.scss so that we know which styles are associated to that module.
18. Comets, naturally are generally quite small, thus very specific, one off types of files exist here. Things like page specific styling. Or styles that pertain on one page specifically. Default error pages (like the 404 page) Styling and layout exist within these sass files, since these are always specific, there’s no need to modularize these files for easy use elsewhere.
19. Lastly the debris. This is where our shame lies. Any !importants, or awful emergency fixes that need to happen live here. If anything exists here we come back to this folder later, and correctly sort out the debris into it’s correct folder and file. Emphasize that these file names and folder structures are a part of our development process. This thinking would translate to any CMS we chose. This process of file and folder naming makes troubleshooting and working on other internal developers projects so much easier.
20. MAMP is a local server environment application Gives you access to PHP, PHPMyAdmin, and MySQL. All essential for running a Wordpress theme locally. As far as process goes, we have 3 servers that developers will push to, our, development environment, where things are always broken, modules in progress etc, testing environment, this is where our QA and QC steps occur. More on that later, and our preview environment, where the client will review their site before giving the go-ahead to go live. We push from our local environments to our development, testing and preview environments. To ensure database consistency our databases are always prefixed with an identifier for the server, followed by the project name.
21. Every development team needs some sort of version control to prevent catastrophic overwrites and terrible terrible headaches. Something I’ve definitely never experienced… I’m not the most versed in the land of git, but we have a few very slick git hooks that will push up the databases in addition to the files whenever we make a change. And depending on the branch you are on locally, it will push up to the correct server. The one thing that we do make sure to do process-wise, is write clean, well thought out commit messages.
22. At this point a site has made it through all of our rigorous process…we’ve followed our development checklist, made added site customizations modularly through our zemplate folder structure, we’ve made a bunch of very semantic well written commits. The last few steps are all centered around testing, testing, and then some more testing to ensure that we work out every possible bug that we can.
23. The developer will go in on their own and browser test their site in our supported browsers. We support Chrome, Firefox, Safari, and IE on the desktop. All of which are essentially the latest public release, and the two major versions prior to that. We also support IE11, 10, and 9, and it’s great. Next Slide…
24. Any version prior to IE9 is bad, and it should feel bad.
25. As far as mobile goes we support The latest versions of Safari on Apple devices, and Chrome on Android.
26. Once the dev is confident all browser bugs have been squashed, and the site is, in the opinion of the dev on the project ready for production the site gets submitted for code audit. Senior developer will sit down with the dev on the project and go over the code at a high level. Crucial to ensure a consistency in the way that our code is written. We’ve found that when working with multiple devs it is crucial to ensure the code can be traversed by any developer at the company. We check the modularity of template parts, integrity of BEM code, We test the site speed, ensure speed on slower connections. Check that the code quality is up to snuff. Comments in correct places. Are !importants used? I’m pretty well known at Zenman for making developers write out explanations when an !important is used…I’m very specific about specificity. Vastly important. Yields learning experiences for both people in the meeting. If one process can be afforded in your business, add this one.
27. Fresh set of eyes on the project. This new person will scour the site on all browsers again, makes note of any discrepancies between design and production. Tester tries to break any piece of functionality, form, error message, 404 page etc. Goes through any scenario a real user might go through.
28. Once QA is complete someone from business side of things ensures contractually, everything has been addressed and delivered. We again test this in all browsers to make sure we didn’t miss a single thing.
29. Client sees the site at this point. Allow them chance to review the site and give one round of feedback. Gives client a chance to add or edit any last minute content or imagery, get their hands on the site before approving for launch. When alpha list comes back, we do a review meeting to ensure no requests are out of scope.
30. Most process intensive step, but most crucial. Imperative that everything goes smoothly, and based on the other processes, the hope is that you caught absolutely everything. This is our chance as developers to check, check again, check one more time, freak out because we have a ‘feeling’ that we missed something, realize we didn’t, close our eyes, and then hit the button.
31. This is our staging and launch checklist. Built from years of trial and error, these are all of the checks and tasks that we preform during each and every launch, big or small. At a high level, the major things we do are things like - backing up the old site, ensuring things like javascript and CSS are minified and optimized, remove extraneous themes that were used for testing, any unnecessary files - things like .DS_Store, and sass cache, confirming permissions on certain files, and many many more.
32. Thank you!