Sometimes, when you've got your sleeves rolled up and your hands deep in the innards of a project, it can be helpful to take a step back and look at the bigger picture. I don't just mean the context of the overall project, but the even wider context of the medium we're working in. For us, that's the web.
Last week, I ran a workshop with some developers from one of our big clients. The workshop wasn't directly about the project we were working on. Instead, it was a chance to pull back and look at what's on the horizon for development on the web.
We started by brainstorming all the possible topics that we could look at: think of a technology and scribble it down on a post-it note. At this point, there are no bad ideas. Everything is allowed. Nobody can pooh-pooh what someone else writes on a post-it note. This is one of those "Yes, and…" exercises, rather than "No, but…"
Once we had a big hodge-podge of tools, technologies, and techniques, we sorted them into two columns. One column was for user-facing technologies—things in browsers, mostly. The other column was for developer-facing technologies—things we install on our own computers to help us work faster. I wasn't sure how to label these columns: "outward" and "inward"?, "public" and "private"?
Anyway, once the topics were sorted into those two categories, it was time to prioritise. We used dot voting for this. Everyone got the same amount of sticky dots to distribute as they saw fit. We tried to do this all at once so that we couldn't be influenced by other people's choices.
From there, we had a clear list of what we wanted to discuss, and in what order.
We took a look at the practicalities of writing code with accessibility and performance in mind. We also dived into the guts of web components and service workers, technologies that have a lot of buzz around them.
I used a meta-framework for evaluating those technologies. As well as asking "how well does it work?", we also asked "how well does it fail?" That can really help clarify if a technology is worth pursuing yet. If a technology isn't widely supported, but the lack of support isn't going to have a negative effect on the user experience, then that technology is a good candidate for adoption. If, on the other hand, a technology demands that you go "all in" in order to use it, making it a requirement for the users to complete basic tasks, then it's worth having a long hard think about whether to adopt that technology.
This particular workshop happened to be on a Thursday, which is when we have our front-end pow-wows every week, so the two events segued nicely together. Together we discussed the more dev-facing tools and techniques like coding style and component libraries.
There were a few exercises I didn't get around to doing. I was hoping to have a quick-fire round for all the post-its that scored lower in the dot vote. I was also thinking of having a user-story centred approach to choosing technologies: we all write down issues that users are currently facing ("the site is slow", "the site doesn't work well on my device", "the site is frustrating to use on the train"), and then see if those problems can be matched up with solutions from the pile of topics.
This was my first time running this kind of workshop, but I thought it went pretty well. Everyone seemed to enjoy themselves. The refreshments on the beach at lunch time might have helped.
In this instance, the workshop was with an existing client, but there's no reason why it wouldn't work as a standalone offering. So if your company would like a wide-ranging, free-flowing workshop on taking a future-friendly approach to evaluating web technologies, get in touch. I'd definitely like to do this again.
