On Being an “Un-Opinionated” DeveloperReading Time: 3 minutes
I was on TLDC Chat (a great community, if you’re looking for someplace to get involved with some L&D folks!) a little earlier this month and one of the things that we discussed briefly was an idea that’s been running in my head for a bit: being an un-opinionated learning experience developer. I wanted to delve into that a bit more here.
In software development, an opinionated framework is one that guides you into one particular way of doing things and trying to diverge from that path will make your life very difficult. Now, being opinionated isn’t really a bad thing(as the responses to this question on Stack Overflow point out very well). For example, an opinionated framework can be very helpful because it makes the decision-making process easier and encourages consistency and the use of best practices. As a learning experience designer/developer, you should be asking questions and offering opinions about what you think the best course of action is for a particular learning product with a particular audience and constraints. Still, in one sense of “opinionated”, if you’re always used to doing things one way or using one tool, then you can become dogmatic about the right way or the best way (or the best tool) and that can be a stumbling block, perhaps especially for a newbie like myself.
As I’ve continued to grow and experiment, I’ve come across a variety of tools that allow me, not necessarily to replace a purpose-built elearning authoring tool, but to augment it in a variety of ways. For example, as I’ve said before, I find it hard to suggest to anyone that they should make any kind of reasonably complex game inside of an elearning tool; I’d always recommend using a game development tool instead. I’ve also found increasingly in my work as an independent LX Designer/Developer that having a bunch of tools that I know and can wield allows me to continually say “Yes, and…” to clients. In one recent client request, we wanted to build an interactive experience that would promote an “Aha!” moment for participants around the diversity of their classroom. The requirements of that particular experience were:
- generate any number of beads (which represented different diversity factors, such as race) to separate into groups (meaning a person could potentially create an infinite number of beads; undoable in an authoring tool without scripting),
- drag and drop items into groups on the screen (easy in an authoring tool), and
- take a picture of their resulting, sorted groups (undoable in an authoring tool without scripting; possibly undoable at all, without using the HTML5 Canvas)
Now, of course, I could have made part of this in an authoring tool, then told the client the limitations and found some workaround. But because I have other tools in my toolkit, I didn’t have to say “No, but…”; I could, instead say, “Yes, and…” As it happens, I prototyped this solution in about 4 to 6 hours using Phaser JS. After, reviewing it with the SME, we decided to pivot to having participants enter in data to create a dynamic chart of their classroom data across three different diversity markers and I was able to develop that in another 4 to 6 hours using Chart JS.