We’ve all been there. You work meticulously to craft lean, efficient, elegant code. Beaming proudly, you hand your little sweetie off to a client, a contractor, a colleague, or even a CMS, but the next time you check in, everything has gone to hell. Or worse – you’re on the receiving end of a long line of shitty code, trying to make sense of deprecated tags, naming collisions, arbitrary plugins, and other code soup.

So what happened? Where did all this cruft come from? And short of hunting down the abusers and beating them with Eric Meyer’s 2lb “CSS: The Definitive Guide”, what can you really do about it?

In this brutally honest session, front-end & back-end coders will unite with project managers to play the role of shrink, surveyor, and sensai. Using real-life examples, we will break down how bad code happens to good people, why it matters, and specific steps you can take to prevent it. Come learn why it’s important to code like the next person to use it is a homicidal maniac who knows where you live.

Presentation Notes

How does this happen?

• Different standards or conventions
• Spanning multiple CMS’s/CRM’s
• Competing libraries
• Plugins
• Failure to separate design/data/behavior/content
• Laziness

Why it matters?

• Self-satisfaction
• Delivery
• Maintenance

What to do about it?

• Flag Issues in Process
• Collaborate Across Disciplines
• Build Rapport
• Know When to Compromise, and make sure to check yourself

“Most of the evil done in the world is done by people who think they are doing the right thing.” – Richard Beck

There are many failure points when coding between teams: HTML, CSS, front ends, back ends, etc.

External Links

• Pea.rs
• Sparkbox Pattern Library
• H5BP

Simplify and speed up your CSS development with Sass. Overcome browser differences – particularly with CSS3 – and build grids the right way with Compass. Sass is a CSS meta language that brings more functional programming to the css language and complies to standard browser supported CSS. It adds tools like variables, functions, and mixins, as well as compilation tools for debugging and optimization. Compass builds an additional framework of tools on top of Sass. It adds mixins for almost all the new CSS3 modules to abstract away syntax inconsistencies and browser prefixes. It also enables the development of CSS frameworks *the right way*, using semantic classes instead of presentation oriented classes. Compass has ports Frameworks like Blueprint, YUI, 960.gs, as well as even some Compass only ones like Susy. On top of that, there are also loads of extensions to Compass for everything from CSS3 button generators to more complex sprite and image generators.

In this one hour tutorial workshop, you will become skilled in CSS3 selectors, transforms, transitions and animations. We will work through an animation examples, creating different paths, timing and effects, exploring linear gradients opacity, alpha transparency, border-radius, text-shadows, transforms, transitions and mostly animations. The code example will be provided participants can play with the code, going from novice to skilled without heavy note taking.

If you build it, they might not come, if you haven’t thought about how search engines view your web site. Forget testing for Internet Explorer, Firefox, Chrome and Safari. Search engines are the common browser that everyone uses. The good news is that search engine optimization (SEO) doesn’t mean terrible design or some type of black-magic trickery. Rather, there are good, sensible things that everyone should do that pleases both search engines and human visitors. In this session, representatives from Google and Bing provide this type of advice. They’ll even get you up to speed on the impact that social media is playing on search results. Even better, it’s all Q&A. Bring your top questions about how they rank sites and get answers directly from the source.

Presentation Notes

The “Deep Links” or “Site Links”, which are the links that are listed under popular webites in search results, are determined based on what content on that particular website is accessed the most by relevance and value. You can go into Google’s Webmaster tools, or Bing’s version, to remove any if you don’t want them… but you cannot add them. See: searchengineland.com/seotable

Google is working on leveling the playing field to make people who SEO a website without relative content not be as high in the search results as they are now. These changes should be rolling out within the next couple months. The best way for a mom-and-pop website to get ahead in SEO is just for them to have awesome products and be engaged socially. Rather you’re involved or not is your choice, but those signals still exist by others.

Don’t buy links. This is one of the worst things you can do, and this will hurt you in one of two ways: 1. you’ll waist your companies money, or 2. you’ll hurt your domain in search rankings forever.

Infographic: The Google Panda Update

If you have a website page that no longer exists, you should do a 301 redirect. If your IT personnel wont grant you that, then tell them both Google and Bing say they’re stupid. See: rel=”canonical”

So why does one website who posts after me get a higher search ranking? Well, typically it’s because users are more comfortable with that bigger company. But that’s not to say there isn’t other things you can do. See: http://schema.org/

In the early days of CSS the web industry cut its teeth on blogs and small personal sites. Much of the methodology still considered best-practise today originated from the experiences of developers working alone, often on a single small style sheet, with few of the constraints that come from working with large distributed teams on large continually changing web projects.

The mechanics of CSS are relatively simple. But creating large maintainable systems with it is still an unsolved problem. For larger sites, CSS is a difficult and complex component of the codebase to manage and maintain. It’s difficult to document patterns, and it’s difficult for developers unfamiliar with the code to contribute safely.

How can we do better? What are the CSS best practises that are letting us down and that we must shake off? How can we take a more precise, structured, engineering-driven approach to writing CSS to keep it bug-free, performant, and most importantly, maintainable?