Art, Tech, And All The API Keys
A post mortem of txtr and sext adventure
This is a post about some thoughts and experiences I had when building txtr, and Sext Adventure (referred to as SA in this). Overall, it was a mixed bag. Some of it was good, some of it was bad. But good and bad aside, it was definitely a thing that influenced me on a lot of levels.
Ready? It’s quite long…so get a coffee:
1. Experimental projects can be difficult to sell, and costly to support.
Arty tech projects can be a great way to experiment. But they can also be very needy. When you’re running a setup like SA with a service like Twilio, extra costs can add up quickly. I love working with texting. It’s a fun medium and it has a lot of potential for experimentation. But the wallet strain on running something like this can be a bit much. After about a year, the project had to come off-line. That’s not necessarily a bad thing, but it is just a reality of arty tech stuff.
Experimental web and tech projects also generally need an end date or they become zombies. So be aware that if you want to do some arty tech, you’re going to need a budget for keeping your systems and services going. If you’re the tech end on something experimental, be advised it will always be in need of something, and there will likely be little to no money in support, unless there’s a bunch of funding. You’re going to have to decide how much you can realistically give, and when it is over for you, because if not, well…this image says it all.
You also need to set out some hard rules about initial size, and potential growth. One of the caveats with arty tech stuff is scope creep (Oh! It can light up, and be movement reactive, AND also tweet! And… o_O). Now that can happen with any kind of project, but if you have, say, 3 custom pieces of hardware, and some software to upkeep…that can snowball really fast. Set your limits. Stay in them.
2. “It’s not ideal but it’ll do…”
SMS and MMS over the web is pretty fast, and places like Twilio spend time making decent docs to help encourage on-boarding. But you can still run into issues that have nothing to do with your app and instead have to do with the inherent nature of cell carries which you have no control over.
Example: for a long time, MMS wasn’t available outside of Canada using these systems. How do you deliver images, over SMS, without out using, well, images.
Web links turned out to be a solution, tho not ideal. But sometimes you just have to be ok with what you got.
Delayed delivery in MMS due to cell networks can also be an issue. This meant things would come out of order sometimes. If you’re just sending a one off now and then that’s not a big deal. But in a situation where people are playing a game that latency can kill the experience. The expectation is that everything will be immediate. Working around that requires some thought, or some bodging, experimenting with file sizes, etc. There were also issues with certain carriers who block services like Twilio and in those cases it took some log crunching to figure out what was going on.
In the future, for myself, exploring texting setups that are less immediate short session orientated, and more drawn out, is something I would like to try. Services and notifiers are things we’re already used too. It would be interesting to see them implemented in re-mixed contexts.
3. Dealing with Web APIs
Web APIs are funny beasts. I once heard a presentation that described them as a large dragon that both spits AND poops flames. You sort of put something in one end, and it pops out the other…where it went? Who the fuck knows. It’s tempting to think of them as magic sometimes. But that thought quickly vanishes when you have to trace something, and you can’t see into one of the boxes.
Other challenges included dealing with various web API rest times which can cause time outs, and OAuth flows.
I had no idea that OAuth would be so confusing. I really thought it was just me. But no…apparently not. I did not expect payment to be one of the biggest pains in the ass, but having to split payments was difficult because certain services to do that in the API used, weren’t available in Canada. This meant doing a convoluted work around that took a while to figure out, which in the U.S. Would have been fairly simple. So remember, if you’re not in America, something will probably be missing. Something you need.
Also, while it’s straightforward to get started with a lot of these APIs keep in mind you will be limited to the lower tiers of web services unless you’re a biz, or have decent funding. Which is ok! Lots of good things can be found in those service tiers. But you’re not going to be doing anything super big on the hobby dev plan. Scale accordingly.
There’s also questions about data and privacy. These are 3rd party software as service APIs, they store logs, they spit out info left right and centre. And if you do tech on a project, you access those logs, and that info, to figure out what the issues are. It’s a really weird feeling.
4. People not understanding what it was or how it was made.
Initially there were posts that listed SA as an iPhone app, and the internet, being a snowball, ran with that for a bit. Which sure, you can play it on an iPhone. But when developing an SMS based engine it was important to me, that it was platform agnostic (it’s written in Python, its headless, it runs online). Using just SMS means you can play things on a smart phone. But if you don’t have one, you can still play it.
I fielded a decent amount of support emails asking “Where do I download this app!” then I would have to explain it was a timed web game. Which leads to the next thing: how do you explain timed access? You have to approach it like an experience (eg: going to a show, or a movie), rather than a thing you download and own. That’s a tough sell. Especially in a world where downloading is at the tip of your fingers.
5. I was unprepared for how lopsided the media would report on it
I figured that would happen, but I was really surprised at how bad it was. Most things published about SA contained errors, credit bungles or omission of work, and incorrect technical information, that could have been avoided from the get go by just reaching out. But media doesn’t really have an interest in talking to techs.
There’s a long running history of tech just being left out of the public conversation on creative projects. I think in the case of experimental games, or installations, that use creative implementations of technology, this is problematic. You see it happen even with high profile projects like Somebody and Beme. Where devs are just a by-line, or dev houses don’t even get a by-line.
Leaving techs out of the conversation has real world consequences in terms of authorship and discoverable credit, even if projects acknowledge contributions. People have baked in biases when it comes to what is considered creative and what is thought of as technical, and assumptions about how those things coexist and interact. Is a texting game still a texting game without the texting? I don’t know, that might be a philosophical question. But the experience would be dramatically different.
Tech shapes experimental projects more than is generally considered. And building those experiences is an organic process where content and framework intermingle a lot. Tech is not just a delivery system for some amorphous thing called content. Tech is content.
5. Authorship, acknowledgement, and discoverable credit
When it came to SA I struggled with a lot of it. From its implementation and premise, to its upkeep, and coverage, but I still did the things I said I would do. However, those personal wrestlings are why I made a separate entity called txtr.
In hindsight that was maybe even more confusing to the outside world. But at the time it seemed like the right thing to do, because I was trying to figure out how to deal with questions of discoverable credit and authorship. A large part of SA’s innovation as a text based game, was wrapped up in its mechanic, and how people related to that. I wanted the code base to be its own thing, to not be tied to that one project. To not be assumed it was written specifically for that project, because the core mechanics had been designed and built independently prior to SA’s existence.
It was difficult, because again, wider society views things like writing, or visual design, as legit on projects, but things like code, not so much. Coming from a visual design background into programming, I feel that’s starting to change, but it’s still messy, and hard to traverse. I really wasn’t sure how to navigate it, and that caused some personal contradictions.
I also feel there’s a lot of entitlement out there towards code. The question I was consistently asked during SA’s run was “Is there a repository where I can access your code?” I’ve since published txtr on GitHub (minus the web and database layer). But at the time I wasn’t sure where to go with it. Would I seek to develop it more? Would it become a tool? How do I feel about any of this? It felt strange and off putting to be asked to post a repo all the time by total strangers. Yet open source publishing remains one of the most visible ways to show authorship and retain discoverable credit in programming, even if acknowledged on a project.
I’m not going to further unpack authorship and credit things right now as that could be a whole post on its own. But it is a conversation I’d like to explore more. Especially in the light of the next point.
The people I collaborated with the most during txtr and SA, were other programmers. I was pretty new to the programming rodeo, and their contributions and insights, were incredibly helpful. They were friends who walked me through deployment when I was learning. Who helped me with debugging and troubleshooting. Who wrote the database layer, and made contributions when I hit my knowledge wall. Who lent their expertise, time, and a hand, because they were interested. It was an eye opener to me that basically laid out that programming is not a solitary activity. And that sometimes your most valuable collaborations are not necessarily always with the people directly involved on a given project.
It also made me start to think about how we make things. How we all build on each other’s knowledge and experiences. And why contributing back to code bases, or posting those interesting implementations, and work, can be really important to the development community. I get that now. We use each other’s stuff and we don’t do anything alone. Acknowledging that is something I have become far more cognizant of, and vocal about.
7. Final Thoughts
During a panel at Vector last year, someone asked “What do you think the revolutionary role of the artist is?”
“Revolutionary role of the artist…..? I thought. WTF is this guy on about?” I remember feeling annoyed that someone would ask that. It was so god damn pretentious. In that moment I couldn’t really think of how to describe the term artist. It felt almost one dimensional when you think about all of the frameworks you interact with, and people involved, to make a thing real.
I started to think that maybe our language around artist and art is outdated. We make such intertwined things now, touched by many different hands, built using complicated tools, and processes, that are explorations in their own right. We exist in this framework that ebbs between things. In squads, in tribes, in the digital ether of recursive dreams, and gifs. In systems we’ve built, and torn down, and rebuilt. Virtually, professionally, and creatively.
Maybe our perceived ideas of what is art or what is tech, or what is an artist or what is a technician is showing its age. Maybe it’s time to figure out a new way to be, and a new way to talk about all the amazing things we make with each other.
Maybe its time to rebuild our system again.