Our team goes to StirTrek every year because it's a great conference. One big change this year was the location. In years past, StirTrek was held in a movie theater, which was awesome. But it seems the success of the conference led to them outgrowing that venue and moving to OSU's Schottenstein Center. The move makes sense because it is bigger, but as an attendee, the new venue offered only cramped seating and challenging acoustics; each session was divided only by a tall curtain and you could hear the sessions on the left and right of you. This was not a user experience improvement. But hey, just like in websites, it's the content that really matters...right?

So what new knowledge and ideas did our team bring back with them this year? Check our session summaries below.

Why your agile isn't

Travis Alexander

We transitioned to Agile a few years ago, there is always more to learn and improve on, so I tend to gravitate to these types of talks, even if I only pick up one or two new things, and this session had a few great bullet points. In no particular order:

• Epics are just to group stories that span across sprints
• Use sub-tasks like a checklist for your user story
• How do you keep story points from being a time estimate (and age-old agile debate)? Establish a baseline of shared understanding for something that everybody has done, such as adding content to a modal. That's a "two". Now, all of a sudden, everyone has a common point of reference to estimate the point estimates from.

No Estimates, or Lean Estimates, That is the Question

Chris McClellan

It was ironic that this session followed the "Why Your Agile Isn't" (in the exact same room no less) because some of the ideas seemed to directly contradict the notes I took from the previous speaker. In this talk, Chris explored the pros and cons of not giving estimates at all, or finding a compromise and using something called "Lean Estimates". Lean Estimates seemed to be a more reasonable solution where estimates are not given until the are needed (JIT), and are not debated endlessly by petulant team members who are more concerned about being right than getting things done. Not that anyone has ever had that happen.

For a short time, I did not think there was any value in looking back at sprint work estimates. They are just estimates and estimates are never actual so why look back - keep moving forward. In presenting Lean Estimates, Chris really changed my way of thinking. He conveyed that using historical data can help get you quick estimates for forecasting the future. If we keep a snapshot of past done stories/items per sprint, we can use the count of those to estimate how much we think we can typically get done. When the squads are really gelling a common throughput trend will stand out. He started to see that Week 1 they got 13 cards done, then Week 2 12 cards were done, then 13 again, and then 10. This is extremely valuables to see, before even looking at the next sprint you can estimate we will get around 12 cards done.

More Better Code Quality

Jim Holmes

I always love to hear how developer teams work big and small. Jim walked us through a simple and typical development lifecycle from Idea through Building and finally to Production. He pointed out how and where you should be using collaboration to discuss quality considerations. One point he stressed in the building phase, was using the 3 Amigos. This can be a quick 5-minute discussion before the developer dives in where the developer, tester, and BA/Product Owner review the story with their different perspectives. This story kickoff should result in an agreement on what is needed to get it done correctly. As a developer when I see a story with good acceptance criteria I just want to dive in knock it out and throw it over to QA but there are so many things wrong with that will end up costing more time in the end.

Fetch and Service Workers - Revolutionizing Web Requests

Jared Faris

JavaScript conference talks are always tricky. Sometimes you can sit through 45 minutes of something that is only implemented in 1 browser or something that is demoed so generally that you have no clue how to use it in something you are working on. But this is never the case with Jared Faris, he has a tremendous way of presenting through real demos. I would recommend seeing him present whenever possible. In this session he first reviewed the Fetch API, which he wrote on back in November of 2016. At Aztek, we've used the Javascript library Q to flatten our callback pyramids with promises and get implicit error propagation. The Fetch API is something useable today with or without a polyfill to get that generic asynchronous Request and Response for data to and from the server. Seriously, start using it today.

The latter half he showed off the arrival of the less implemented Service Workers. Service Workers will give use developers really easy and powerful ways to handle caching, offline and even push notification going forward. I see a lot of benefits in these when they get settled and adopted and will probably start digging in by using them to inject additional calls for telemetry in our applications.

Make Your Team More Effective From Within

Jason Blackhurst

In this very concise talk, Jason broke down the results from Google's Project Aristotle, which explored what makes a project team successful. The results? There are basically five things that your team needs to perform at their best (and of those five things, really only three matter). They are:

• Psychological safety
• Dependability
• Structure and clarity
• Meaning of work
• Impact of work

If you've got those things covered, you're gonna have a good team. The problem, of course, is that doing those things well is hard.

The UX of Voice

Tim Rayburn

Voice/chat as a UI continues to gain momentum and if you believe Tim Rayburn, this is the year Voice is poised to explode the way mobile did a few years ago. So the key takeaway here was to get into voice now, so you can be part of the early adopter crowd. This goes for designers, developers, and brands alike. After that big message, Tim's talk focuses mostly on Amazon's Alexa platform.

A few smaller, more tactical takeaways:

• Keep answers short (two items), ask user if they would like more
• Interrupting skills (Skills are what Amazon calls an application for Alexa) loses the entire session
• Use SSML for phonetic spelling

We recently bought an Alexa for Aztek, and are looking forward to hacking on it and experimenting with our own Alexa Skills.

Use Alexa to Learn Cloud Serverless Skills

Wray Mills

In keeping with our new found interest in Alexa, we attended this talk right on the heels of the UX of Voice session. This session was way more technical. Wray took the audience on a tour of all the places and steps a developer needs to get familiar with to write their own Alexa Skill. He covered what accounts, what services, what technologies, etc. you need to get started developing your own Skill. The bad news for me was some of it was way over my head (what do you want, I'm a designer), but the good news it, it wasn't so over my head that I was intimidated. Wray assured us that even a newbie could have their first Alexa Skill up in a weekend.

And just in case you thought Alexa was only for playing music, check out what he did with his.

Girl Develop It

(Stir Trek Spaces)

This was one of the unofficial sessions for people who wanted to present a topic but maybe didn't have a full 45-minute talk ready to go. I have twin daughters who might be interested in what Daddy does for a living in a few years, so I wanted to find out what Girl Develop It was all about. From their website: "Girl Develop It is a nonprofit organization that exists to provide affordable and judgment-free opportunities for women interested in learning web and software development. Through in-person classes and community support, Girl Develop It helps women of diverse backgrounds achieve their technology goals and build confidence in their careers and their everyday lives."

Two representatives from the Dayton and Columbus chapters talked to us about the various events they sponsor and how their classes work. I also learned that next to California, Ohio has the largest number of GDI chapters. Surprisingly, however, there is no Cleveland chapter. Right then and there I submitted an interest form to let them know that I thought Cleveland could benefit from its own chapter. Go to https://www.girldevelopit.com/ to learn more about this great organization.

Planning for Accessibility

Jeff McWherter

Accessibility is something all web developers should strive towards. As Jeff pointed out in his talk, studies show that as much as 20% of the population has a disability, and we should try to accommodate as many of them as we possibly can. There are a lot of confusing and sometimes conflicting standards out there, and Jeff did his best to make sense of them for us. A lot of this I already knew, but it's always good to hear this stuff from someone who knows more than you because there's always something new to learn.

• WCAG (Web Content Accessibility Guidelines) and Section 508 are the gold standards for accessibility, but compliance with one does not necessarily mean you automatically meet compliance with the other
• WCAG has three levels of compliance - A, AA, and AAA. Level A rules are generally easy to meet and should not impact the appearance of the page much, if at all. AAA, on the other hand, can be pretty difficult to achieve and may significantly impact content or appearance of the page.
• NoCoffee is a Chrome extension that can simulate a number of vision disabilities, including low acuity, contrast sensitivity, colorblindness, and visual obstructions like glaucoma or diabetic retinopathy
• Color Safe (http://colorsafe.co/) is a website that helps you create attractive color palettes that adhere to accessibility guidelines for text and background contrast ratios

Event-Driven UX in the Real World with Angular 2 and Socket.io

Michael Meadows

Introduction to Functional Reactive Programming

Corinna Cohn

I really want to learn more about Angular, React, and functional programming. Unfortunately, two 45-minute sessions at a conference like this is not the best way for me to learn much. These talks both went pretty much over my head. I will have to do much more of my own homework before this sinks in.

Building An Audio Microscope: Freezing and Exploring a Moment of Sound with PureData

Krista Campbell

I wanted to attend something "cool" for the last session, regardless of its applicability to web development, and Krista's talk fit the bill. Using an open-source programming language called PureData, created for processing and manipulating audio and video data, Krista created an application she calls and "audio microscope". Normally, when you slow down or speed up a sound clip, the pitch is lowered or raised in direct proportion to the speed change, and if you pause the sound, it just stops. Unlike video, where you see a still clip when the video is paused, sound requires motion to work, so if you stop the motion, there is no sound. Krista's app overcomes these limitations (with a lot of complicated math that I did not understand, but that's ok, because it's cool). She can load a sound clip, speed it up or slow it down without changing the pitch at all (sing "Happy Birthday" to yourself REALLY slowly but stay in the right key), and she can even "pause" the sound for an indefinite period of time and it will continue to play that small sample of sound (start singing "Happy Birthday" to yourself but just hold "Haaaaaaaaaaaaaaaaaaaaaaaaaa" as long as you possibly can). It's difficult to describe her talk accurately in words, but it was pretty neat.

Until next year...

As always, another great year at StirTrek. As an added bonus, our own Keith Rowe won a brand new XBOX1 from one of the vendor raffles!