This talk digs into how optimizing for search and using the existing technical assistance forums can put your product ahead of the pack. Technical writing, in all its variations, is a type of interface with your product. It incorporates everything from an error message to an implementation guide. How can you as a web producer make deploying, using, and promoting your site as painless as possible? Make it searchable. Make finding the answer to a problem so trivially easy that your user barely even remembers they had a problem.

No one wants to be using software. They want to be data mining or manipulating beautiful photos or targeting advertising. Making them think about the software diverts them from what they want to be accomplishing. Use these documentation techniques to get them in and out and on their way.

Takeaways:

• Use search terms to drive development
• Understand failure modes in users
• Use outside resources to improve site development
• Test changes to site content

Attendee skill level: Audience should have some familiarity with analytics, SaaS concepts, and accessibility.

Visit the site with materials from this session.

The first step in building or maintaining an accessible web site or application is identifying accessibility issues. Yet accessibility testing is something that feels overly complicated, requires special expertise, or is time-consuming. It doesn’t have to be. Really. Come find out how.

In this session, we will demonstrate simple checks for accessibility that can be easily integrated into your web development process including the use of free easy-to-use tools. In addition we will discuss what types of checks should be done at certain points while developing or updating a web site or application to catch a majority of web accessibility issues.

Getting into the habit of checking or web accessibility, like all good habits, can be hard. Checking for accessibility doesn’t do a lot of good unless you check often, so we will discuss possible tactics you and your team can take to insure accessibility is checked for over the long run.

At the conclusion of this session, participants will be able to:

• Perform simple accessibility tests
• Describe when accessibility tests should be performed
• Describe some common testing tools
• Describe some common accessibility issues
• Tactics for encouraging continued accessibility testing

Attendee skill level: Introduction. This session is aimed at members of a web development team, both technical and non-technical, who want to feel empowered to find accessibility problems.

There you are, minding your business, aggregating your CSS and JS while waiting for your morning toast. Then the Vogons arrive, and they’re wiping out your front-end performance best practices to put in a new intergalactic superhighway, http/2. What’s a front-end developer to do when everything starts spinning, and we still need to stay on top of life, the universe and everything? The answer is more complicated than “limit yourself to 42 requests.” Should we still concatenate our front-end assets into great big lumps on all our pages? Or are we now free to scatter small modular files willy nilly? Don’t panic! New front-end performance techniques need not be entirely unlike what we’ve learned so far about optimizing our source order, CSS, JS, fonts and images to leap across the galaxy as quick as can be. We’ll look at what the advent of http/2 means for us, when to begin changing our strategies for speed, and how to stay calm despite the whirling vortices surrounding us all.

In this talk, we’ll look at how http/2 affects front-end performance. To do that, we’ll recap some basics of how browsers process web requests, and how that’s changing in http/2. We’ll look at where the web is in terms of adoption of http/2, and when the right time is for us to tweak our optimization strategies. Best practices and real-world results take time to develop when a sea change like this happens. So it can be challenging to know how to adapt when there are no definitive answers. We’ll work through some of the options for aggregation strategies, font loading and image optimization that are available with emerging changes. The goal is not to definitively say “Here’s the new way to do things,” but to evaluate various tactics, and encourage attendees to further ponder and investigate and share what they learn as they experiment with new front-end performance optimizations. 

Takeaways:

• Reconsider aggregation strategies for CSS and JS
• Look at other performance strategies like font loading and responsive images
• Look at various stats and studies on http/2, and what that might mean for your site

Attendee skill level: Intermediate to advanced. Some familiarity with front-end development performance optimization may be helpful, but we will cover the basics of what you need to know.

“Hope for the best and plan for the worst.” We spend a lot of time talking about best practices: the ways we should run our projects and write our software so that everything turns out as well as possible. But when you add human beings to the mix—whether they’re coworkers, clients, or, well, you and I—something will eventually go wrong.

Using case studies from the interactive agency world (where no two clients are ever the same), we’ll talk about methods for triage, what to do when you sense a project is on shaky ground, and ways to ensure everyone gets to the other side in one piece.

After this talk, attendees should:

• Know when and how to use The Five Whys to find an issue’s root cause
• Understand the value of empathy, communication, and flexibility when dealing with client issues
• Have tools to deal with emergency situations: 1) Step back, 2) Make a plan — And understand the ideal for a *good* plan (What you’re going to do + How you’re going to do it, with flexibility and trust built in)
• Have tools to clean up after emergency situations: 1) Cultivate a blame-free culture, 2) Circle back and prevent the issue from happening again
• Believe in the awesome power of the checklist at *least* one third as much as I do
• Know what an incident response plan is, know when to use one, and have a framework for creating their own

 Attendee skill level: This talk is accessible to anyone with even a small amount of professional software experience (role not important, but parts are geared towards developers and people like PMs and team leads who work with them). However, it contains content that may be useful even to people who have been doing this for a while.