We just finished alpha testing for the event setup function. Our alpha testers gave us some fantastic ideas and critiques—thanks, everyone! Testing cycles don’t just point out problems and opportunities in product functionality. They also improve our understanding of how you think about your events and how you expect your software to behave.

While Brian makes updates to the code (and spends some time out of town), I’m moving forward on design for the slot/scenario/table setup function. We’re entering our next “sprint”—a block of time in which we develop a section of the new site. Sprints are part of a methodology called “agile development”. The idea is that you prioritize the project into manageable chunks, prioritize working software over comprehensive intra-company documentation, and rapidly iterate instead of exhaustively spec’ing. Put simply, you cut as much waste out of the process as you can without sacrificing usability or stability.

Agile is a development model that works well for small teams like Brian and me because it keeps both of us busy all the time. During each sprint, I test the things we built during the previous sprint and spec the things to build during the next sprint. This (theoretically) keeps Brian’s task list full of revisions and new coding. In a more traditional system, he’d be sitting on his hands a lot of the time waiting for a big pile of documentation from me—and then I’d spend a big stretch of time waiting for him to work through all the coding.

The slot setup design is pretty challenging so far but I think we’ve got some neat interface ideas that should make it easy and intuitive. Stay tuned!

One of the things Brian and I are bringing to Warhorn 2e is improved support for other Organized Play (OP) systems beyond the RPGA. In order to make sure we do it right, we’d love to talk with coordinators for any and all OP systems out there. If you know an OP coordinator (or if you are an OP coordinator), please drop me an email at finn [at] warhornllc.com with contact information! Much obliged.

I’m deep into 2e task flow documentation now. Put simply, it’s the process of breaking down every little thing you can do with Warhorn to a fine level of detail. You don’t just set up an event: you click a “set up a new event” button, enter an event name, shift your attention to date entry, decide whether your event is recurring or one-time, input that choice into Warhorn, and so on.

It’s a long and fatiguing process, but it’s a majority of the brainwork for how the site is structured. Thoroughly documenting interactions ensures that we catch the tricky questions early on in the process. For example, if you’re “cloning” a previous event (a new feature in Warhorn!), how many options does Warhorn display? Every event you’ve ever organized? Only the most recent ones? If the latter, what does “recent” mean? These are questions we want to answer right up front so we don’t get caught in the middle of coding and have to backpedal.

I find this part of the design process fascinating because it’s the first time I get to put myself in your shoes. I’m not worried about how hard it is to code, or how the pages are laid out, or even what functions go on what pages. I’m solely concerned with how you, a Warhorn player or event organizer, go about your various interactions with Warhorn. Once I’ve got those down, I can start building screens that make your interactions easy to accomplish.