Language and Mobile Development - A Postmortem on Terminology and Teams

Fuel isn’t your average company - as a startup, we’re not exactly a game team and we’re not exactly a technology team. Our first foray into the mobile space was with Fuel Compete - an asynchronous multiplayer SDK for mobile games. In order to expand our platform to encompass several products, we embarked on releasing a new product, and with that, a new SDK. 

With this new product, Fuel Ignite, our focus was to provide a game team a way to create and manage a set of activities we call “live events”. These live events leverage existing single player activities and place them into one of two categories. One is an event with “leaderboards” which allows a player to participate with a group of peers vying for a top position during the period of time the event is active. The second is a mission where one or more tasks are given to be accomplished during the period of time the event is active.

On one level this all seems fairly straightforward - until you have to build it. All of a sudden it becomes apparent how easy it is to misinterpret this top-level design. This kind of problem can manifest from day one of a project. Simple ideas like “activity” and “event” are so ambiguous that describing them in terms of what needs to be built is confusing. Everyone comes to the table with their own understanding of what they mean, and therefore what the end goal is.

Words or Ideas?

Language might not be the first thing that comes to mind when you think about building something - and that’s a mistake. 

A common understanding of language might be that it is “just communication”, which would suppose that it’s simply a way to telegraph something to other people, a method to get a point across. But what’s your point in the first place? Just think about working alone, or even just sitting alone. I’m betting that there is some internal chatter you can detect. Unless you’re a Zen master, you’re probably subvocalizing to yourself all the time. You’re “thinking”. 

From the moment you start planning, you are already internally conceptualizing the task and chances are this is simply going to be reflected when you choose to flap your gums at a teammate about the feature as well. You’re always walking into a project with a bundle of implicit assumptions under your arm. Those are your conceptual tools (and they’re important and necessary), but keep in mind you also privately constructed them.

What you’re doing in a team is passing these private concepts around - making them public. And then, miraculously, you expect other people to intuit exactly what you mean. Your control over how your concepts are digested by those people on the outside is admittedly limited.

So, what I’m talking about is not just “semantics”, but the transmission of ideas. Imagine for a second two engineers: Irene and Tim. Irene would like to build a new thing, and she conveys her ideas to Tim - it should work like this or that, and the end result should be such and such. Tim nods in agreement and then gets to work. A week passes by, and to Irene’s horror, Tim has been building the thing all wrong.

Who’s at fault? Both of them, really. We often take our understanding of something for granted when communicating. Now have Irene talk to a designer, a producer, or an artist, and it’s essentially like people speaking different dialects of a language to one another. Maybe they even use the same terms for different purposes in their respective disciplines. Mayhem. So the first step to building something has got to be: What is it, what do we call it, and why? Plain Terminology Is Critical When trying to discuss something technical, it is important that everyone is able to understand the information that your concepts are trying to convey. A great example of terminology failing is the police-speak “10-4” uttered over a radio. A decade ago in Virginia, a "10-50" in police-speak meant "a motor vehicle accident." But in adjoining Maryland, "10-50" became "officer in trouble." The same code in these different contexts packs a very different meaning, and elicits a completely different kind of response - it’s ripe for misunderstanding. 

Now, the police swap “10-4” for “Message Understood” - opting to use plain language in communications. One person’s use of a term, especially once it becomes jargon, may be completely different than someone else’s. This is a lesson for all of us to remove jargon and acronyms when trying to communicate complex new ideas, and to attempt to communicate them in plain language in order to avoid confusion.

This does present a problem, though:  At some point, you need to use specific, information-dense terms to ensure that what is desired is understood without ambiguity - sometimes, there is a good reason for jargon, as it condenses a lot of meaning. This is obvious when trained people within some discipline are discussing a domain they already share a common understanding about. Part numbers, IC pin numbering conventions, and specific movements in a dance routine are all good examples of using something that is well understood given the target audience. As fun as it is to show how well you've memorized some esoteric names for the domain in which you want to be proficient is all well and good. Good for you. But when you are talking to someone for the first time, telling them to Arabesque or connect the ground wire to pin 5, you can’t assume they will understand - this is no longer good for anyone. This fact is amplified if the action to be taken is intended to be done by an otherwise untrained individual once or twice a month.

So what can we do? Describing the problem in terms of what the end-user sees and/or does is really helpful in order to really get at the concepts related to the tasks at hand. Applying the terminology of other products can confuse things and make your goal unclear, although it may assist in getting people heading the right direction because of familiarity. 

An example of this that is fresh in my mind is the difference between a template and a preset. In our user-facing operations web-app, I didn't like referring to certain modules used to configure event attributes as “templates”. As a user, you aren’t presented with a preconfigured structure that has been filled in and expanded for you, but rather a collection of literally pre-set attributes you can tune. These pre-set attributes are then referenced by the live event, which acts as a sort of container, to be used as a customized mission type. But it ended up being the case that people prefered talking and thinking about them as templates - regardless of the fact that it doesn’t really fit the dictionary definition. 

Sticking with the term “preset” internally, however, assisted in engineers clearly conceptualizing what it did while developing the product – instead of thinking about them as templates which has loads of other baggage, and could have led us in another direction. Terminology floats around a development team rather freely no matter what you try to do to control it, so in one respect here it was inevitable that some team members would be more comfortable “thinking in templates”, while others would find “thinking with presets” more handy. In any case, it was vital that the actual development of the feature stuck to using the idea of “preset” as the actual guiding principle.

Since we are developing a tool here which we expect to be used by game developers, we also need to keep in mind that we’re also essentially designing terminology for the people using the tool to operate their game’s live events. When we talked about using an early version of the system internally, we initially talked about things like rule tags, rule filters, and variables. These made a certain sense to us - since we were privy to information gleaned during development, but they had to be curated in a different way in order to be understandable by our target users.

Assuming Everyone Knows What to Do

As development progresses, and developers add more details to the system, a sanity check needs to be done regularly. This helps clarify and disambiguate the language you are using and the goals we are trying to achieve. 

Attention is selective, and limited. When discussing any topic, people will tend to focus on a subset of the whole in order to find a handhold for meaning. It’s not feasible in development for a complete, all-encompassing discussion to take place early on unless the topic is mind-blowingly trivial (and then, why discuss it in the first place?). So, to get everyone working toward the same goal, we met at fairly regular intervals to rehash what exactly it is that we are building. This helped in two ways: one was to reinforce the goals that we are trying to achieve, and the other is to enlighten folks on parts that were not comprehended in the previous presentations for different individuals.

Being conscious of the ins and outs of a concept requires attention. The saving grace when discussing implementation details around a technical topic is that there are a bunch of facts to lean on - you can take steps to make the problem less abstract and more discrete. 

One of the tools we use to help us get there is to write a simple game alongside development of the SDK that could expose all of the features we need to build. This way you’re forced to encounter and build for the kind of integration issues you can expect clients to hit - you become your first user, essentially, and this informs development This is a double-edged sword, of course, since attention is selective - it means you risk focus being diverted rather than focused. This means that part of the time we are building an SDK, and the other part of the time, building a game to use that SDK. There’s always the risk of becoming too involved since it is easy to get lost in the details of the game, we can find ourselves working on things that are not needed to prove the SDK works, but building a game that is more fully featured.

As we add features to the various parts of the system, whether it is the SDK or the test game, we can slowly see that we are hitting the mark. This allows us to see if the different ideas we’ve implemented work in a real-world scenario. We feel that this type of development for validating an implementation is critical to ensuring a deployable SDK. By and large getting a system in a visually testable form is very desirable to communicating what should and should not happen (and why). Some people might say that unit tests are the way to go, and though they are super helpful too, they don’t move you to making the right choices in developing a product that needs to expose what makes the software helpful rather than simply implemented correctly to spec, but I digress.

Different End Users Need Different Information

After having established a game to demo the SDK, it quickly became apparent how powerful it is to be able to point at a feature in a working system and say, “That’s what is meant by event.” Or say, “A rule means that the event will show up under these circumstances.” Even so, the terms come into play here. 

When creating our SDK, there are at least 5 user archetypes to consider with different, but related, needs.

The Developer: The people who are responsible to get the SDK integrated into the game.

The Operator: The person who use the tools we provide and make sure the;game is managed from day to day.

The Analyst: A person who reviews the performance of the operations to see what is effective and what is not for that game.

Fuel SDK Developer (us): The team that makes sure that the SDK is doing; the right things and is kept running.

The Players: All of those fine folks whom are taking an interest in a game and making it a success.

Conclusion

Describing the details of the product to each of the parties in meaningful and consistent ways is challenging. It also makes for many revisions and refinements to the documentation after we released it to the public. 

One of the conceptual challenges that we faced was bringing out the idea of a “tag” that separates out the concerns for each of the archetypes. This word seems simple to understand in the abstract, out of context, but within our context relates nothing about use of the system nor the end results of use. 

From the Fuel SDK Developer point of view, the idea of a “tag” was an idea conceived in order to identify the entity used. We could talk about it with logical operations (equal, and, or, not) and provide complex ways to “turn on” an entity. 

After discussing this functionality we came to the conclusion that all of those nuances are overkill, and probably massively confusing to operators who might be prone to making errors if given such an unconstrained tool. 

So we started talking about this entity as being a “filter”. Filters help the end user (the Operator and the Developer) understand what they are for (rather than what it is). It’s much easier to describe that when you add a filter to an event, only Players which match that filter will be funneled in to see that event. A practical example: A “magic event” will have the “wizard” filter, and a Player who is a “wizard” will see that event. The Player who is an “archer” will not. This allows us to understand that there is a filter for “eligibility” for an event and that these “filters” provide a way to allow players into an event and .

To get to the final and relatable terms that we can have users interact with, we went from “tag” to “filter” to “event filter” to “eligibility”. All of these ideas were stepping stones which led to the production of a more meaningful description. And, in the end, it is most important that the end users are able to understand what it is that the features do. One of my mantras is that, “If you can’t describe it in a single sentence, you don’t understand it.” Terms matter to your audience more than they do to you, and bridging that gap is of paramount importance to the use of whatever you make. Hopefully we got close.